How to keep Jira Cloud audit logs longer than 180 days

[#1]

If you administer Jira Cloud, sooner or later an auditor asks for a year of admin activity, or an incident review reaches back six months, and you discover the hard way that the audit log is not a long-term record. It is a rolling window: records older than roughly 180 days age out and are gone. This post explains why that gap exists, how to work around it with native tooling, and where the workarounds run out.

📉 Why your audit history disappears

Jira's audit log is built for recent troubleshooting, not evidence retention. It keeps roughly the last 180 days of activity; older entries are removed and there is no native way to get them back. SOC 2 and ISO 27001 evidence requests routinely span a year or more, which puts the requirement well outside what the platform keeps.

Longer retention is a long-open request on the Jira issue tracker. JRACLOUD-68267 ("Jira audit log retention period needs to be increased") is still gathering interest with about 226 votes and 156 watchers as of this writing, and the same ask recurs across Community threads whenever someone hits the window mid-audit.

🧰 What you can do with native tooling

The core idea is simple: because records vanish on a schedule, you have to pull them out on a schedule, well before they expire, and store them somewhere durable. Two native routes:

• Scheduled manual CSV exports. Put a recurring reminder well inside the 180-day window (monthly is comfortable), open the audit log under Settings, then System, apply a date range that overlaps your previous export, and export to CSV into a controlled evidence store. Watch the export caps: the org-level export tops out around 10,000 activities, and the larger product-level export does not honor the filters you set in the UI, so split big ranges into several passes.
• A scheduled REST API job. For a hands-off version, script against the auditing API (`GET /rest/api/3/auditing/record`), which supports date filtering and pagination. Run it on a cron, deduplicate by record id so overlapping runs never double-store, advance a cursor so each run fetches only what is new, and append to storage you control.

The honest limits: both routes work, and the cost is entirely operational. Someone has to own the schedule forever, because one missed month inside the window is a permanent hole in your evidence. The manual route fights the row caps; the scripted route needs somewhere to run, somewhere secure to store a growing archive, and maintenance when the API shifts. And neither can recover anything that aged out before you started.

🗄️ One option that fills the gap: Compliance Log Vault

Disclosure: I work for Katabarwa Labs, and we build a small app for exactly this gap, so treat this as one option among whatever you evaluate.

Compliance Log Vault automates the capture loop inside your own tenant. It retains every audit record it syncs, so the vault's span keeps growing past the platform cap: a year in, you are holding months of history that native Jira has already deleted.

The sync is a daily scheduled Forge function that pulls new audit records from a stored cursor and appends them incrementally, deduped by record id, so overlapping syncs never double-store an entry and no one has to remember an export day again.

When an audit lands, you export the entire retained vault as clean CSV in one click, one row per record with id, timestamp, author, category, summary, and changed values, with retention stats (counts by category and day, plus the full retained span) to show exactly what the evidence covers.

Here is a short walkthrough of the app in action:

https://youtu.be/S1mdAPhSxwU

It runs entirely on Atlassian Forge (Forge functions, a daily scheduled sync, and Forge storage) inside your own Jira Cloud tenant, so your audit history never leaves your instance. It requests only read scopes and changes nothing in Jira. Honest limits, stated plainly: it retains from install forward, so records that aged out before you installed are gone for good; it keeps what Jira records and cannot add event types the native log does not capture; and retention is bounded by Forge storage quotas (typically years of history at moderate audit volumes, with the capacity used shown on the admin page so the bound is never a surprise).

If a calendar reminder and a locked evidence folder cover your compliance needs, use them. If you want the capture loop to run itself, the listing is here: Compliance Log Vault

If the app is close but missing an export shape or filter your auditors need, tell us what that is and we will build it.