An append-only record of what was deleted, what an administrator changed, and who signed in.
An append-only record of deletions, configuration changes and sign-ins. Stock Redmine keeps a journal of issue edits, but not of who removed a project, who changed a workflow, or who signed in from where. That question can come from an auditor, a customer, or your own team after a surprise.
Redmine's issue history is good. Every field change on a ticket is recorded, dated and attributed, and it has been for years. The gap is everything that is not a ticket.
A project disappears and there is no record of who removed it. A role quietly gains a permission it should not have. Someone changes a workflow and three teams notice the following week. An account is locked, an API key is reset, a sign-in fails eleven times from an address nobody recognises. None of that is in the issue journal, because none of it happened to an issue.
Deletion. Issues, projects, wiki pages, attachments and time entries. The things that leave no trace behind them by definition, which is exactly why they need one.
Administration. A user granted or revoked administrator rights, an account locked, role permissions changed, a custom field changed, a workflow changed, a change to application settings or to the settings of anything installed on top of Redmine, a project archived, closed or reopened.
Security. Sign-in succeeded, sign-in failed with the attempted name and address, sign-out, password changed, API key reset.
Bulk. A bulk issue edit is recorded as one event carrying the ids and the count, not as two hundred rows. Burying the log is its own kind of losing the information.
Every event carries when, who, from which address, what it acted on, and where a change has a before and after, the difference between them.
This is the part worth being precise about, because every product in this category uses the same phrase. Here it means there is no route that creates, updates or deletes an event, and the model refuses both update and destroy outright. The retention purge is the single exception and has to identify itself to get it.
The difference matters. A policy promise is a statement about intent, and it holds until somebody with database access decides otherwise. A missing endpoint is a statement about capability. An audit trail somebody can quietly correct is not evidence of anything, and the only way to be sure is for the correction to be impossible rather than discouraged.
A second promise sits alongside it: recording an event never aborts the action being recorded. Deleting an issue succeeds even if the audit write fails, because a full disk should not stop your team working. The honest cost of that is that a failed write is a missing event, and the log cannot tell you one is missing. Failures go to the server log at error level, which is where that evidence lives.
Passwords are absent rather than redacted or hashed. A password-change event has no value fields at all, and neither does a failed sign-in. Any setting whose key matches a secret-shaped pattern has its value replaced with a redaction marker in the diff, and the matching is done on the key rather than the value, because a token is just a string and no heuristic reliably recognises one. An API key reset is recorded and the key itself is not.
The reasoning is simple. The audit trail is read by more people than the things it audits, since that is its whole job, so a secret written here is a secret spread wider than it was before.
Audit data is kept for three months on Plus, six on Business and twelve on Enterprise. An administrator can choose a shorter window within their plan's ceiling, and options above it are not offered rather than accepted and ignored. The viewer states the window in force, so nobody has to remember it.
Events past the window are deleted automatically. There is no scheduler behind that: the purge runs lazily, at most once an hour and in batches, on the next write or the next time somebody opens the page.
If retention length is part of why you are reading this, it is the clearest reason in the product to be on a higher plan. Enterprise keeps audit data four times as long as Plus. The plan table shows the ladder.
One permission, View audit trail, granted per role. That is deliberate: the person who answers a compliance question is often not the person who administers the workspace, and making them an administrator to let them read a log is a poor trade.
Filtering covers category, user, project, subject text and a date range. CSV exports what you are looking at rather than the whole table, so the answer you hand over is the answer you were asked for. Alerts are per action: tick the ones worth an email and give a recipient list, and mail is sent at the moment of the event rather than by a nightly job.
The audit log is on the Plus, Business and Enterprise plans. Compare the plans, read more about how RedminePRO is secured and where data sits, or see the rest of what RedminePRO adds to Redmine.
14-day trial on any plan. Full Redmine administrator access from the first day.