How to Know If a JSM Queue Is Actually Being Triaged or Just Piling Up
An SLA badge that says "within goal" tells you the clock hasn't run out. It doesn't tell you whether anyone is working the ticket. Those are two different measurements in Jira Service Management. The queue view is built to show you the first one: a countdown, sorted by how much time is left before the next target breaks. Whether a request has an owner, a plan, or a linked piece of engineering work is a separate question that nothing in the queue answers by default.
The check that actually answers it doesn't look at the SLA at all. It looks at whether the ticket has a linked issue, whether anything has changed on it in a set window, and whether the assignee field is honest about who owns it. A ticket can pass every SLA goal Jira tracks and fail all three of those, which is exactly the state a queue is in when it's quietly piling up under a wall of green badges.
Why "within SLA" and "triaged" are different questions
Jira Service Management's SLAs are built from conditions: a start condition, an optional pause condition, and a stop condition, all defined per SLA goal by a project admin. Atlassian's own setup docs walk through adding these as "Start counting time when," "Pause counting time when," and "Finish counting time when." The pause condition exists specifically for cases like waiting on the customer to reply, so the clock stops penalizing the team for time it doesn't control.
That's a reasonable design for measuring response speed. It's a bad proxy for triage state, because none of those three conditions reference ownership, an assignee, or a linked issue. A ticket sitting in "waiting for support" with the clock paused and a green badge can have had zero human attention in nine days. The badge only reports on the conditions it was built to watch.
Queues make this worse by design, not by accident. Atlassian describes queues as commonly sorted by SLA remaining time specifically so agents work the most time-sensitive request first. In Atlassian's words, "a clock on the work item indicates the time until your team's next target is due." That's the right sort order for triage speed. It's the wrong sort order for triage completeness, because a ticket with plenty of SLA time left sorts to the bottom regardless of whether it has ever been touched.
The audit that ignores the SLA clock
Three checks, none of which reference the SLA field:
- Linked issue, yes or no. A request with real engineering work behind it should have a linked Jira issue. One with none, past whatever grace period your team agrees on for "someone should have looked at this," is a candidate for the pile.
- Last activity date. Not the last SLA update, but the last comment, status change, or field edit. A ticket can be untouched for two weeks and still be within every SLA goal it has.
- Assignee reality. An assignee field with a name in it isn't proof of activity; people get auto-assigned and then move on to something else. Cross-reference assignee against last-activity date, not against the SLA badge.
You can build a queue around the first two checks using advanced JQL in the queue's filter. Atlassian's newer queue-creation flow even offers a Rovo chat shortcut that writes the JQL for you from a plain-language description, which is worth using if hand-writing JQL isn't how your team normally works. A filter like "updated more than 14 days ago and status not in (Resolved, Closed)" catches the stale-activity half of the problem cleanly.
The question JQL can't natively ask
The linked-issue half is harder than it looks, and this is the part that trips teams up. JQL's issue-link field (Atlassian's current docs call it the work item link field) only supports checking whether a ticket is linked to a specific other issue or list of issues, for example workItemLink = ABC-123 or workItemLink in (ABC-123, ABC-456). There's no supported IS EMPTY or = empty on that field, and Atlassian's own JQL field reference lists no function for it either. You can ask "is this linked to the issue I already know about," but you cannot natively ask "does this have zero links of any kind."
In practice that means a plain JQL filter can't produce a clean "unlinked tickets" queue on its own. Teams either accept a manual scan against a stale-activity filter, or bring in a Marketplace app that adds the missing function. Neither is a criticism of JSM's design so much as a gap worth knowing about before you build a dashboard around a query that doesn't exist. It's the same gap that shows up in routing linked-issue updates: the automation Atlassian ships assumes a link already exists. Getting it created in the first place, or noticing it's missing, is still on a person.
How far this scales by hand
At low volume, a filtered view and a fortnightly scan through it is enough. You can hold the stale tickets in your head and chase down which of them actually need an issue filed. That stops working once a queue is running a few hundred open requests across several request types, because the "no linked issue" check has no native filter to lean on, and a human has to open each candidate ticket to confirm it's really stuck and not just quietly fine.
Watching the queue continuously and flagging the gap directly becomes the job at that size, rather than a person re-running a stale-activity filter and manually checking each result for a link. Modem sits exactly there. It reads Jira Service Management requests alongside the rest of a team's customer channels and tracks each one as a topic that ages independently of the SLA clock. A request with no linked issue and no real activity shows up as aging, whether or not its SLA badge is green. Modem is what we build, so treat the next few sentences as a vendor describing its own tool, not an independent product review; the JQL audit above is the right first move regardless of what handles the ongoing version of it.
Two related fixes sit on either side of this one. Upstream, routing feature requests to a dedicated queue with a no-close-without-a-link rule keeps new tickets from entering the stale pile in the first place. Downstream, once you've found the requests that are actually being worked, ranking them by how many customers asked is the natural next question.
The check you can run this afternoon
Open your JSM queue's underlying JQL, add AND updated <= -14d AND status not in (Resolved, Closed), and read the results by last-activity date instead of SLA remaining time. Then open each one and check for a linked issue by hand. JQL won't do that part for you. If more than a handful come back both stale and unlinked, that's your actual backlog, and it was invisible from the dashboard the whole time.
