Blog · 2 October 2026

Jira hygiene: the checks, the filters, and a routine that sticks

Jira hygiene is the routine work of keeping a Jira space trustworthy: every open work item has an owner, a status that matches reality, the fields your reports depend on, and a reason to still exist. A clean space is one where a filter, a board or a dashboard tells the truth the first time you look. Good hygiene comes from a small set of checks run on a fixed rhythm, plus a way to make sure that rhythm survives a busy month. One heroic cleanup a year does not get you there.

This guide lists the checks worth running, gives a JQL filter for each, and then covers the part most teams skip: making the cleanup come back on its own.

A note on words. Jira Cloud has been renaming things, and much of the interface now says spaces for projects and work items for issues. This article uses both.

Why Jira hygiene decays #

Nobody decides to let a space rot. It happens one reasonable shortcut at a time:

• A work item is created during a meeting, with a title and nothing else, and never revisited.
• Someone leaves the team, and their assigned items stay assigned to a person who no longer looks.
• A status called "In Progress" holds work that stopped three months ago.
• An epic is finished in practice, but nobody closes it, so it shows up in every roadmap view.
• Labels multiply: frontend, front-end, FE, ui, all meaning the same thing.

Each one is small. Together they make the board lie, and a board that lies gets ignored, which is when people start tracking real work in spreadsheets and chat threads instead.

The Jira hygiene checklist #

These are the checks that catch most of the decay. Each one comes with a filter you can save once and reuse. Replace ABC with your space key.

Weekly checks are about the work in flight. Monthly and quarterly checks are about the clutter around it. Splitting them that way keeps the weekly pass short enough that people actually do it.

Stale open items #

project = ABC AND statusCategory != Done AND updated <= -90d
ORDER BY updated ASC

Anything that has not changed in 90 days is a candidate. For each one, decide: close it with a resolution that says why ("Won't do", "Duplicate", "Obsolete"), or move it back to the backlog with a comment saying it is still wanted. Pick a cutoff that suits your pace; 60 days for a fast team, 180 for a slow one.

Unassigned work in progress #

project = ABC AND statusCategory = "In Progress" AND assignee is EMPTY

A work item in progress with no assignee means either someone is working on it without saying so, or nobody is. Both need fixing, and this filter should come back empty every week.

Items assigned to people who left #

project = ABC AND statusCategory != Done AND assignee in inactiveUsers()

inactiveUsers() returns accounts that have been deactivated. These items will never move on their own. Reassign them, or return them to the backlog unassigned so the team sees them at the next planning.

Missing key fields #

project = ABC AND statusCategory != Done
AND (duedate is EMPTY OR priority is EMPTY OR description is EMPTY)
ORDER BY created DESC

Adjust the list to the fields your reports actually use. If your weekly report groups by component, then component is EMPTY belongs here. If nothing reads a field, stop asking for it: an empty field nobody needs is clutter in the form.

Stuck in one status #

project = ABC AND status = "In Review" AND status changed BEFORE -14d

Change the status name and the window to match your workflow. The point is to find the middle statuses where work goes to wait. If the same status catches items every week, the fix is usually in the process (who reviews, and when) rather than in the items.

Finished epics left open #

Jira has no single JQL clause for "every child is done", so this one is a short manual pass. Open the space's epic list or the timeline view, filter to epics that are not done, and look for any whose progress bar is full. Close those, and re-rank the rest against the current roadmap.

Label, component, filter and dashboard sprawl #

These are the quarterly jobs. Merge labels that mean the same thing, remove components with no open items, and ask the owners of saved filters and dashboards whether they still use them. A Jira admin can change the owner of filters and dashboards left behind by people who have gone.

Who owns Jira hygiene #

Hygiene that belongs to everyone belongs to no one. The pattern that tends to hold:

• The team lead or scrum master owns the weekly pass. It takes ten to fifteen minutes with the filters above and fits right before planning or standup.
• The space admin owns the monthly and quarterly passes, because closing epics, merging labels and reassigning filters need admin rights anyway.
• Everyone fixes their own items when a filter names them. The owner of the pass assigns, comments or asks; they do not quietly edit other people's work.

Put a name on each pass. A pass with a named owner gets done; a pass that "the team" will do gets done once.

How to make the cleanup come back every week #

The checks above are easy. Remembering to run them is the hard part. A calendar reminder tells someone the cleanup exists, but it does not put the work on the board, and a skipped reminder leaves no trace. The cleanups that keep happening are the ones that exist as a work item, with an owner, a due date and a checklist, because a work item that sits undone is visible to everyone.

A weekly hygiene ticket might look like this:

• Summary: "Jira hygiene, week of 5 Oct"
• Assignee: the team lead
• Due date: Monday
• Checklist (as subtasks): run the unassigned filter, run the missing-fields filter, run the stuck-in-status filter, chase anything still open from last week

A monthly one adds the stale-items filter, the inactive-users filter and the epic pass, assigned to the space admin. A quarterly one adds labels, components, filters and dashboards.

There are three practical ways to get those tickets created on schedule.

By hand #

Fine for a small team where one person owns the ritual and rarely takes leave. Add "create next week's hygiene ticket" as the last subtask of this week's one, so the chain carries itself as long as nobody breaks it.

Jira Automation #

As of October 2026, Atlassian's documentation describes the Scheduled trigger this way:

You can run the flow at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules.

That makes two different hygiene rules possible. One creates the weekly ticket for a person to work through. The other skips the person entirely: the same trigger accepts a JQL query, and Atlassian's page says that "actions in this flow will execute on the work items included in the query." So a scheduled rule could comment on every stale item, or transition it to a "Needs review" status, every week.

Be careful with the second kind. An automatic close is the one hygiene step a machine should not take on its own, because the item it closes might be the one somebody still needed, and nobody reads a bulk closure. Commenting and flagging are safe; closing is a decision. The same documentation also notes that "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically," which is worth knowing before you rely on one for months. The trigger options are compared in Jira automation examples, how rules are counted is in Jira Automation pricing, and a fortnightly or "first Monday" schedule usually needs a cron expression.

A scheduling app #

Recurring Work Items for Jira is built for the first kind of rule: the ticket that a person works through. A space admin writes the rule once, with the work item type, summary, description, assignee, due date, labels and an ordered list of subtasks, which for hygiene is the checklist above. The item appears in that space on the day it is due.

A few details that matter for a hygiene routine:

• Dynamic titles. Titles and dates can carry tokens, so each ticket reads "Jira hygiene, week of 5 Oct" instead of repeating last week's title.
• Next runs before saving. The rule editor shows when it will fire next, so "first Monday of every month" can be checked before it is live.
• Working days and holidays. A rule can skip or shift a date that lands on a weekend or holiday.
• A history. Every created, skipped or failed run is written to the rule's history with the reason.
• A label per rule. Every item a rule creates carries the label recurring-<rule id>, so one JQL search lists every hygiene pass that rule ever produced, done or not. That is a quick way to see whether the routine is really happening.

It runs entirely on the app's own schedule, so it uses none of the site's Jira Automation allowance. It is scoped to the one space you enable it in, so one team's hygiene tickets never land on another team's board. It is free for up to 10 users and costs from $82.50 a year for 11 to 15 users.

A sample hygiene routine #

Put the three cadences together and the routine looks like this:

Start with the weekly one only. Once it has come back four weeks in a row and the filters are mostly empty, add the monthly pass. The quarterly pass can wait until the first two feel routine.

Backlog refinement overlaps with hygiene but is a different job: it is about getting the top of the backlog ready for the next sprint, rather than keeping the whole space honest. Groomed backlog covers that one, and Jira recurring tasks compares the ways to schedule other routine work.

When the manual way is enough #

You do not need any automation for good Jira hygiene. A saved filter and a habit are enough when:

• The space is small, one team with a few dozen open items, and the lead already scans the board daily.
• The workflow is short, so items cannot hide in middle statuses.
• Nobody would read the ticket. If your team treats tickets for routine chores as noise, a recurring calendar slot and the saved filters will do the same job.

What a scheduled ticket fixes is the specific case where the cleanup keeps being skipped, because nothing on the board said it was due.

Common questions #

What is Jira hygiene? The routine of keeping a Jira space accurate: open items have owners, statuses match reality, key fields are filled, and work that is no longer wanted is closed with a reason.

How often should we clean up Jira? A short weekly pass on work in flight, a monthly pass on stale items and finished epics, and a quarterly pass on labels, components, filters and dashboards suits most teams.

Should old work items be deleted or closed? Closed, with a resolution that says why. Deleting removes the history, and a closed item can be found again if the work comes back.

Can Jira close stale items automatically? A scheduled Jira Automation rule with a JQL query can act on every matching item. Flagging or commenting is safe to automate; closing is better left to a person who reads the list.