How to track administrator-made configuration changes?

Question

Hi,

I see that Jira configurations do not maintain 'history of changes'. There are not revisions for configurations of fields, screens, boards, projects, roles and schemes.

The only place to see these changes are in the Admin audit log that only records the event, but not the difference, 'before' and 'after' states.

Then there are user related events, that are logged with the generic JIRA user, so for the most sensitive part, we have no idea who has made the change.

So I wanted to create a set of webhooks for these kinds changes and log the events outside of Jira.

Unfortunately I found there are no webhooks for configuration change events:

https://developer.atlassian.com/server/jira/platform/webhooks/.

They are only available for issues, projects and basic user operations.

How do you go around this problem?

Thank you,

Inna

SPHIOR · Answer

This is old, but it still ranks, so here is where the three things you listed actually stand in 2026.

"Audit logs show events without before/after states" — still true. The REST API schema does define changedFrom / changedTo per field, but the only documented example is a user's email address changing, and which event categories actually populate them is not documented anywhere. They are also typed as plain strings: a scalar pair per field, not a structured diff. You will not reconstruct a workflow definition or a permission scheme document out of them.

"Webhooks for configuration changes are unavailable" — still true. There are no product events for configuration or permission changes, only for content. Anything that wants to detect a scheme edit has to poll and compare rather than subscribe.

"Jira lacks configuration change history" — this one moved slightly. Atlassian shipped an improved audit log experience in August 2026: expanded coverage, a side panel with a JSON tab, filtering by IP and location, and a query language. Worth a look. But note the release said "only the UI will be altered, the existing API will remain unchanged" — so if you collect this by script rather than by hand, none of the new filtering reaches you.

Two practical things that do work today, and that I would do before reaching for anything else:

Set your retention window deliberately, in Settings > System > Audit log. The default is shorter than most people assume and none of this is retroactive.

Export to CSV early in an audit rather than late. The export is capped and keeps the NEWEST events, so on a busy instance the oldest silently fall off the end while you wait.

Nic's answer above is still the highest-leverage thing on this page, incidentally — a small admin team that talks to each other beats any amount of tooling. The tooling only helps once you have to prove it to somebody outside the team.

Disclosure: I build a Jira app in this space, so I have read these docs more than is healthy. Not pitching it here — the question deserved a current answer more than it deserved a product.

Inna S · Answer

Thank you, @Nic Brough -Adaptavist-

I won't accept this answer yet, to see if anyone else would want to chime in.

Nic Brough -Adaptavist- · Answer

Very simply put. minimise the number of people who can make changes and make sure they are in a team together.

My standard recommendation is that you should have a Jira project to track all change requests and a team of ideally 2.5, but maybe up to 10 for a very large DC suite.  (The 2.5 is two people with admin rights and a third who has it just in case the two main ones are on holiday/sick/leaving at the same time)

Generally, you shouldn't be trying to automate administrative changes, and there isn't really any need to log them if you've got your administration team working together properly.