How to find out who deleted a Jira issue

When an issue disappears, the first question is usually “who deleted it?” — followed fast by “and can we get it back?” Jira can answer the first question, at the admin level and within limits. It’s much weaker on the second. Here’s how to find out who deleted a Jira issue, and what that answer does and doesn’t give you.

What Jira tells you natively

Jira’s admin audit log (Settings → System → Audit log) records issue deletion events: it logs that an issue was deleted, who did it, and when. For a recent deletion by someone with the wrong permissions, that’s often enough to answer the “who.”

The limits are exactly where real investigations get stuck:

• Admin-only, and not on the Free plan. A team lead who isn’t a site admin can’t just go and check, and on Free the full log isn’t there at all.
• Bounded retention. Older events age out. A deletion from a few months ago may have no record left.
• Not built for filtering. The log mixes every kind of site event together and isn’t designed for “show me deletions of issues in this project” — you scroll and squint.
• It records the event, not the content. This is the big one: the log shows the deletion happened, but it does not store the deleted issue’s fields, comments, or history. You can learn who deleted it — not what you lost.

The gap: who, but not what

Put those together and the native answer is half an answer. On a good day the audit log tells you who removed the issue and when. It never tells you what the issue contained — the description, the estimate, the comments, the change history — because that data is deleted along with the issue. So the two questions people actually ask after a deletion (“who did this?” and “what did we just lose?”) only ever get one of them answered natively, and only if the event is recent and you’re an admin.

Closing the gap

An audit-trail app keeps the record Jira throws away — but only for issues it was already watching. Trailkeeper’s paid tier continuously captures each issue’s last-known state and field-change history as it happens, to a store kept independently of the issue itself. So when a tracked issue is deleted, you still hold its last captured state and the trail of who touched it, instead of a one-line “deleted by” event and nothing else.

Why that matters for a deletion:

• The last captured state survives the delete — not the issue’s entire history necessarily, but its fields as of the last change before deletion, plus the trail leading up to it.
• A trail, not a single event — who changed and moved the issue over its life since install, not just who removed it at the end.
• Not admin-gated after the fact — the history is there as a record you can view and export, rather than something only a site admin can dig for within a shrinking retention window.
• Read-only, and since-install only. Trailkeeper never writes to Jira, so recovery means viewing/exporting the captured state and rebuilding the issue yourself — and it only covers issues that changed after you installed it, not ones deleted before.

This pairs with two related questions: what your options actually are once an issue is gone (see recovering a deleted issue in Jira), and why the admin audit log and an issue’s own history answer different questions (see audit log vs issue history).

Which do you use?

• Recent deletion and you’re an admin? The admin audit log answers “who” and “when” — start there.
• Need the issue’s content back, or the deletion is outside retention? The audit log won’t have it — you need an independent issue-history record like Trailkeeper, kept before the deletion, not after.