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

Hi @Steve White ,

One detail worth checking is what `breached()` represents in this case. The function returns work items whose most recent SLA cycle missed its goal. If the SLA can start again, an item may have a previously breached cycle while its current cycle still appears to be within the target.

The board may add another complication. A filter runs the search again when you open it, while a swimlane evaluates the work items already loaded on the board. This can make a time-based SLA result appear outdated until the board or work item is refreshed.

If your main goal is to give the team a reliable operational view of breached work items, another option is to use a dedicated SLA view. For example, SLA Time and Report fot Jira provides SLA Grid report where you can filter work items by the `Exceeded` status and see the remaining or overdue time, target date, assignee, priority, and current SLA status in one place. This also helps the team identify work items approaching a breach, not only those that have already exceeded the goal.

You can also configure an action when the SLA is exceeded, such as changing the priority or status, notifying selected users, or sending a Slack alert.

Depending on the project configuration, the SLA status and target date can also be synchronized with Jira custom fields and used in regular JQL queries.

Hope it helps

Regards!

Hi @Steve White

Are the JSM work items coming onto that software board through a cross-project board filter, or through a linked hierarchy?

I have experienced something similar, as the board swimlane query is applied to the work items the board has already loaded. As a time-relative function like breached() looks correct in Filters (search runs live against the index every time you execute it) and stale in a swimlane, items might sit there until the browser is refreshed or a reload of the board is triggered when something actually changes on the work item.

Cheers, Martin

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.