Audit Trail for Redmine · RedminePRO Docs

Q: Old events disappeared.

Keep events for elapsed. Raise it, within your plan's ceiling, and export regularly if you need a longer record.

A record of the things the issue history cannot tell you: what was deleted, who was granted administration, who signed in and failed, and which two hundred issues changed in one bulk edit. Every event carries when, who, from which address, what it acted on, and, where a change has a before and after, the difference. It cannot be edited from anywhere in the product, and it never blocks the work it observes.

What you can do

Availability: Plus and above.
Turn it on: Nothing to turn on.
Permissions: A global capability, holding it in any role in any project unlocks the log everywhere.
Settings: Changes to these settings always alert and that cannot be unticked. Turning the record off is a first move worth knowing about, and an alert somebody can quietly disable is not a control.
Using it: Open Audit trail.
What is never recorded: Passwords. Not hashed, not masked, absent.

The recorded events, with their filters — From a live RedminePRO workspace.

Configure

Settings, permissions, modules and how to use it on RedminePRO Cloud.

Install on your own Redmine

Requirements, install, update and remove, for a self-hosted Redmine 6.

Common questions

An event I expected is missing.

Recording never aborts the action being recorded, which means a failed write is a missing event and the record itself cannot tell you. That evidence is in the Rails log, at error level, marked as a failure by this feature.

Ordinary issue edits are not here.

By design. The issue history already holds those, and duplicating them would bury the events nothing else records.

Old events disappeared.

Keep events for elapsed. Raise it, within your plan's ceiling, and export regularly if you need a longer record.