SLA Met vs Breached Report

Question

I am attempting to utilize the SLA Met vs Breached report on a Service Project in Jira Cloud. However, tickets are showing on the report that should not be. Below is the SLA met vs breached report showing 100 met and 5 breached in the last 7 days:

While that report shows 5 breached, there are only four unique issues and only two of those should actually be shown on the report. Ticket 980 shows up on May 16th as well as May 21st (the day the report was generated). As you can see from the "Breached Time" column, neither item shown is actually breached.

When I open the issue, it clearly shows the SLA as being met in 4h 18m:

Below is one of the tickets that did breach and correctly shows on the report:

I have attempted to use JQL to modify the results shown by the report. Including "Time to resolution" = breached() does not change the results at all. The same thing is true if I utilize everBreached() instead. If I use "Time to resolution" > elapsed (8h), the report does change but the two issues that are actually breached are removed, leaving the two that are incorrectly displayed (and the duplicate is still duplicated).

The time to resolution SLA is set up as follows:

What could be causing these tickets to incorrectly appear on the SLA report?

Iryna Menzheha_SaaSJet · Answer

Hi @Hunter Wessinger  👋

You're absolutely right to question the inconsistencies — Jira’s built-in SLA reporting in Service Management can sometimes show:

Duplicates for tickets that were updated or recalculated across multiple days

Issues as “breached” due to older SLA cycles (e.g., previously breached goals that were later reset or fixed)

Limited control when using JQL like breached() or everBreached() — especially when SLAs restart or are paused/resumed

Since the reporting relies on internal SLA cycle history, it may reflect more than just the most recent status — which could explain issue 980 appearing twice and falsely flagged.

🚀 Flexible Alternative: Time Metrics Tracker | Time Between Statuses

If you’re open to exploring an app-based solution, Time Metrics Tracker (developed by my team) offers:

✅ Custom time-based metrics — like tracking time from creation to resolution, or time spent in “Waiting for Support”✅ SLA simulation without JSM — You can define your own “breach” conditions (e.g., >8h) and track exact compliance✅ Detailed audit trail — Includes full time breakdown per issue, exportable to Excel✅ No duplicates or ghost breaches — Reports show exactly what happened per issue, per status

This works across both Jira Software and Service Management, and many teams use it to validate or cross-check SLA reports from JSM — especially when accuracy matters.

If you’d like a quick walk-through or sample report to compare, I’d be happy to help!Let me know how you’d like to proceed 🚀

Hunter Wessinger · Answer

The calendar is set up as follows:

Danut M _StonikByte_ · Answer

Hi @Hunter Wessinger,

If you can't solve this, another possibility would be to look for a plugin on the Atlassian Marketplace.

In case you want to try a plugin, our Great Gadgets app offers some gadgets that could be helpful.

Control Chart gadget shows the issues from a JQL or filter by their cycle time - for example from the creation to the entrance in a done-category status, but it can be configured in many ways. It allows you to set a threshold which should your SLA value, and this way it will display in red-color the ones that breached the SLA.

Histogram Chart gadget shows the distribution of the cycle time for the issues in a JQL or filter. It allows you to set a threshold which is your SLA and this way it will display in red-color the number of issue the breached the SLA

These gadgets offers also a Data tab with a detailed report, showing the ones that breached SLA in red-color. It can be easily exported in CSV.

More details in this article: https://community.atlassian.com/forums/App-Central-articles/An-effective-dashboard-for-Service-Desk-and-Customer-Support/ba-p/2360369

Danut.