Most Jira dashboards focus on:
-
Open issues
-
Overdue issues
-
Sprint progress
-
Story points
-
SLA breaches
But there is one question that Jira teams ask repeatedly:
"Which issues have gone quiet?"
Not blocked.
Not resolved.
Not waiting for approval.
Just... sitting there.
No updates.
No transitions.
No comments.
No activity.
And often, nobody notices until a standup, escalation, or sprint review.
The Problem With Traditional Jira Dashboards
Imagine two issues.
Issue A
In Progress
Last updated: 2 hours ago
Issue B
In Progress
Last updated: 11 days ago
Both appear in the same column.
Both count as work in progress.
Both contribute to sprint metrics.
Yet one is actively moving while the other has effectively disappeared.
Native Jira makes it surprisingly difficult to answer questions like:
-
Which issues haven't been touched in the last 5 days?
-
Which stories are quietly aging in the sprint?
-
Which tickets are at risk before they become overdue?
-
Which assignee has the largest backlog of inactive work?
These are often the issues that create last-minute surprises.
Introducing IdleIssues() JQL with StatusClock
While building StatusClock, we kept hearing the same request:
"Show me work that nobody has touched recently."
That's why we added:
issue in IdleIssues(days)
The function returns issues that have been inactive for the specified number of days.
Find issues idle for more than 5 days
issue in IdleIssues(5)
Find issues idle for more than 10 days
issue in IdleIssues(10)
Find idle issues in the current sprint
sprint in openSprints()
AND issue in IdleIssues(5)
Within seconds, teams can identify work that is slowly drifting off everyone's radar.
Why Idle Issues Matter More Than Blocked Issues
Blocked issues are visible.
People discuss them.
Managers ask about them.
Idle issues are different.
They create silent delays.
A developer gets reassigned.
A dependency is forgotten.
A reviewer never responds.
A customer never replies.
The issue remains open, but nobody is actively working on it.
From a dashboard perspective, everything looks normal.
From a delivery perspective, the clock is ticking.
Dashboard Ideas Using IdleIssues()
One of the most powerful uses of IdleIssues() is building dashboards that highlight risk before it becomes a problem.
Sprint Risk Dashboard
sprint in openSprints()
AND issue in IdleIssues(3)
Shows stories that are part of the sprint but haven't moved recently.
High Priority Work Losing Momentum
priority in (High, Highest)
AND issue in IdleIssues(2)
Perfect for daily reviews.
Stale Customer Requests
project = SUPPORT
AND issue in IdleIssues(7)
Find requests that may need follow-up before customers escalate.
Idle Bugs
issuetype = Bug
AND issue in IdleIssues(5)
Surface defects that have quietly fallen through the cracks.
Building Better Dashboards with Combined StatusClock Functions
The real value appears when teams start combining functions.
Find work that is both idle and repeatedly bouncing
issue in IdleIssues(5)
AND issue in StatusBounces("In Progress", ">", 2)
These are often the most expensive issues in the project.
Work that repeatedly moves backwards and has now stopped moving altogether.
Find work sitting in review with no activity
status = "Code Review"
AND issue in IdleIssues(3)
A great widget for engineering leadership dashboards.
Find stale high-risk work
priority in (High, Highest)
AND issue in IdleIssues(5)
Ideal for release readiness reviews.
The Dashboard Philosophy Behind StatusClock
Most Jira dashboards answer:
"What is the current state?"
StatusClock functions are designed to answer:
"What needs attention?"
For example:
StatusBounces()
Find issues creating rework.
issue in StatusBounces("QA", ">", 2)
IdleIssues()
Find work that has gone quiet.
issue in IdleIssues(5)
BusinessDaysInStatus()
Find issues exceeding expected processing time.
issue in BusinessDaysInStatus("Code Review", ">", 3)
Individually these queries are useful.
Combined together, they become powerful dashboard building blocks that expose workflow risks long before they show up in sprint reports.
A Simple Experiment
Create a filter using:
issue in IdleIssues(7)
Run it against one of your active projects.
There's a good chance you'll find work that somebody assumed was progressing but actually hasn't been touched in over a week.
Those discoveries are exactly why we built the function.
Discussion
I'm curious how other Jira teams handle inactive work today.
Do you rely on dashboards, automation rules, standups, SLA monitoring, or something else?
And if you could add one workflow intelligence metric to Jira, what would it be?
