Configuration Change Event Audit Log(2.2.11)

The charts above show patterns — this table shows the facts. Every configuration change is listed here with its date, event type, project, affected issue, and the actor who triggered it. It is the primary tool for forensic investigation and compliance review. During a DORA, NIS2, or GDPR review, this is typically the log reviewers ask to see.

What you can conclude

• Filter by actor to review all changes made by a specific administrator — useful for access reviews or investigating a suspicious event.
• Filter by event type to isolate destructive actions (deletions) and verify they were authorized and intentional.
• Filter by date range to scope the log to a specific audit period, sprint, or incident window.
• Where the event names no actor (field, project, user-account and workflow-definition changes), the actor column reads system: no actor was recorded, which is not the same as an automated change.
• Each actor is also labeled by account type: a person, an app (an automation or integration account, such as Automation for Jira), a service-desk customer, or unknown when Jira did not return a type. Where the actor's account was later erased, the actor column also reads system but the label reads erased: an actor was recorded, and only its identity was removed. An action Jira records under a person's account counts as that person's action, even when a tool acted on their behalf.

How this chart works

Filterable audit table of all schema-level configuration events ordered by timestamp descending. Columns: date, event type (color-coded additive vs. destructive), project, issue key, triggering actor. Use date, project, field name, and actor filters to narrow the view. A user-account event names only the account it is about, and that account is never shown as the actor.