How are you handling Jira audit log retention beyond 180 days?

[Ari]

The audit log retention cap is 180 days and as far as I can tell there's no way to extend it. For anyone who needs to answer questions further back than that (compliance evidence, "who had access to this project last quarter", proving a permission change happened), what are you actually doing?

A few approaches I'm aware of, none of them great:

• Polling `/rest/api/3/auditing/record` on a schedule and dumping it somewhere yourself
• Exporting to a SIEM, though the export is capped at 10,000 activities
• A backup app, which covers restore but not really "who did what when"
• Accepting the 180 days and telling auditors that's the limit

Curious which of these people have landed on, and whether anyone has found something that handles permission and group membership changes specifically. Those only seem to exist in the audit log, so once the 180 days rolls off there's nothing left.

Also interested in whether this comes up for people in practice, or whether 180 days is fine for most teams.

[Germán Morales]

Hi @Ari , for Jira Cloud the 180-day retention is a hard cap: older activities are removed and cannot be recovered. Atlassian Guard Premium or Enterprise can provide broader event coverage and webhook delivery, but neither extends the native retention window.

For compliance, the cleanest design is to collect two separate feeds:

• Organization audit log for user, group, and product-access changes. If your subscription exposes these logs, use audit-log webhooks on Enterprise or Guard Premium, or poll the Organizations Events API. Persist the event ID because webhook deliveries can be duplicated or arrive out of order.
• Jira site audit log for permission schemes, project roles, workflows, and other Jira configuration. Poll the Jira audit records API on a schedule, use a small overlap between runs, paginate all results, and deduplicate by record ID.

The 10,000-activity limit applies to the CSV export, so I would use that only for manual evidence or backfill, not as the retention mechanism. A normal backup also does not replace audit evidence unless it explicitly captures and preserves those events.

For questions such as “who had access on a particular date,” retain the change events and take periodic snapshots of group and project-role membership. The events show what changed; the snapshots make effective access at a past point in time much easier to reconstruct.

[Tomislav Tobijas]

Hi @Ari ,

I know some of our clients (who are under specific regulatory requirements) are using this: 

...Polling `/rest/api/3/auditing/record` on a schedule and dumping it somewhere yourself...

Not ideal, but the thing works. 🫤

I do know there are open feature requests such as these two:

• ACCESS-991: Increase audit log storage and export 
• JRACLOUD-68267: Jira audit log retention period needs to be increased 

And as you'll see in the comments, there are some workarounds and/or Marketplace apps mentioned that you could also check out regarding this.

Keen to see what others have come up with 👀

Cheers,
Tobi