Jira Admin Cleanup Checklist: 6 Things to Automate Before Your Next Audit

[#1]

Here's how Jira instance audits go in most organizations: someone finally schedules one. The audit turns up 700 unassigned open issues, 45 custom fields nobody remembers adding, a project marked archived that still has active issues inside it, and eight users who left six months ago still listed as project leads on active work.

Then someone spends four days fixing it manually. Then, eight months later, same thing.

These things don't appear overnight, they build slowly, over months, invisible until someone stops and looks. And they're almost all preventable with scheduled automation rules.

1. Unassigned open issues older than two weeks

A scheduled rule, every Monday:

assignee IS EMPTY AND statusCategory != Done AND created < -14d

Notify the project lead or post to a Slack channel. Ten minutes to configure. Catches the drift before it becomes 400 orphaned tickets nobody wants to own.

2. Issues stuck in "In Progress" with no recent activity

Pick a threshold - 10 days, 14 days - whatever fits your sprint length. "No activity" means not updated in the last N days. It's not a perfect definition (an update can be a comment, a transition, an automation touch), but it's a reliable enough baseline:

status = "In Progress" AND updated < -10d

Either something is blocked and nobody mentioned it, or the issue is done and nobody closed it. Both are a five-minute conversation if you surface them in time.

3. Inactive users still assigned to open issues

When someone leaves, their assigned issues don't. A weekly rule checking assignees against an active user group catches this:

assignee IS NOT EMPTY AND statusCategory != Done

Add a condition: assignee not in group active-jira-users (or however you track active users: Jira groups, Atlassian Admin, IdP sync). Then notify, reassign, or flag. Set it up once, forget about it.

4. Required custom fields left empty

If specific fields drive your reporting - component, team, priority tier - a scheduled rule finding issues where those fields are blank saves you from discovering the problem six weeks later when a quarterly report breaks:

statusCategory != Done AND "Team" IS EMPTY

5. Labels and components with only one issue attached

One thing to know before you try to automate this: Jira doesn't give you a clean "show me labels used fewer than N times" query through JQL alone. To surface it reliably you need an app with usage counts, a REST API script, or a manual scan through admin screens. The cleanup once you have the list is fast, getting to the list is the actual work.

6. Issues carrying over across multiple sprints unresolved

sprint in closedSprints() AND sprint in openSprints() AND statusCategory != Done

Issues in both closed and open sprints are carryover. Naming them in sprint planning is less painful than finding them in an audit.

Where native automation stops

Rules 1 through 4 work natively. The cross-sprint query in rule 6 works as a scheduled search. The ceiling appears when you need admin-grade actions on top of the detection - field-level operations, bulk issue management across projects, cleanup tasks the standard action set doesn't include.

Automation Actions Bundle for Jira was built for exactly this. Our team added admin-focused actions for field management and issue operations that go beyond what native automation exposes, no code needed. ScriptRunner is the better option if you have Groovy developers on the team. AABFJ is for admins who want more control without a scripting dependency.

Start with rule 1 - go from there.