Difference in JQL results with "time to resolution" in filters vs. swim lanes in cloud

Question

I have a software space Kanban board setup with swim lanes using queries. We also have JSM projects with SLAs.

Attempting to have the top swim lane show items that have breached SLA using "Time to resolution" = breached().

When running this JQL in Filters it properly returns items that have breached the SLA.

When including "Time to resolution" = breached() in a swim lane the swim lane will return items that have not breached the current SLA.

Has anyone else seen this behavior or a way to adjust to show properly in a swim lane?

Alina Kurinna _SaaSJet_ · Answer

Thanks for the extra details, that actually makes things a lot clearer

First, I should fix one thing I said earlier. The breached() function only evaluates the latest SLA cycle, not past ones. So in your scenario with Cycle 1 breached and Cycle 2 not breached, breached() won't pick up that issue. Only ever Breached() would do that.

Since the exact same JQL gives the correct result in Filters, this really looks like a board caching or indexing bug on Jira's side.

The pattern you noticed is the biggest clue here: page reloads bring back the wrong data, but updating an unrelated issue triggers a background refresh that temporarily fixes the swim lane

At this stage, I'd suggest raising a ticket with Atlassian Support. Be sure to share those exact steps with them, especially the part where editing another issue briefly fixes the view

BlueGrove Labs · Answer

Based on your follow-up, I would not switch this query to everBreached(). Atlassian defines breached() as checking whether the last SLA cycle missed its target, while everBreached() matches a work item that failed a target in any cycle. If Issue Navigator is returning the current set you expect, everBreached() would broaden the result rather than explain why the board shows an extra item.

I would reduce this to one work item and one query swimlane:

1. Copy the board's saved-filter JQL into Issue Navigator.
2. Add the exact issue key and "Time to resolution" = breached().
3. Temporarily use the same expression as the only custom swimlane above Everything Else.
4. Capture both results at the same time, then repeat after a full board reload.

Jira's documentation says a query-based swimlane uses one JQL query. If the same issue, board filter, and SLA expression remain different between Navigator and the swimlane after reload, that looks like a reproducible board-versus-search inconsistency rather than a different breached() meaning.

I would raise it with Atlassian Support and include the board ID, saved-filter ID and full JQL, swimlane order and JQL, one affected issue key, screenshots of its SLA cycles, the exact timestamps, and the steps that temporarily make the board correct. Those details should let Support distinguish board refresh/caching from SLA indexing.

Official references:
https://support.atlassian.com/jira-service-management-cloud/docs/write-jql-queries-for-slas/
https://support.atlassian.com/jira-software-cloud/docs/configure-swimlanes/

Disclosure: I work at BlueGrove Labs. Our Jira reporting app does not address this board/SLA behavior, so I am intentionally not recommending it here.

Steve White_16k9qs · Answer

Thanks for your response. The JSM ticket is coming through a cross-project board filter.

What was also reported to me by someone using the board was that they changed a value in a field on an item (not the JSM item in question and not a JSM item at all, it was an item native to the space) and the swim lane refreshed and properly displayed only breached tickets. When they reloaded the board page, everything went back to the way it was (the non breached ticket was in the swim lane).