SLA Met vs Breached Report

[Hunter Wessinger]

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]

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 🚀

[Danut M _StonikByte_]

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. 

[arielei]

Hello @Hunter Wessinger 
Try to press the three dots on the upper right menu of the report and edit it, after that you can click on edit for both the "Met" and "Breached" metrics.

You'll see the JQL it is using, its probably using a wrong configurations, so i would look there.

Hope that helps.

Ariel.

[Hunter Wessinger]

@arielei,

I have tried editing the JQL. However, as outlined in my original post "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 report also shows incorrect data if I instead use the default option "JQL from SLA Goal".

The issue seems to be that the report (including any JQL I attempt to use with the metric display) is seeing non-breached issues as being breached. When looking at the ticket itself the SLA is shown as "Met". And, when looking at the information returned by the report - specifically in the "Time to Breach" column (shown in my original post), the breach time is either not listed or greater than 0 i.e. not breached.

[arielei]

Hey @Hunter Wessinger 
Can you send an image of what are the settings for the BUSSAPPS calendar you are using in the SLA?

I had the same problem a few years ago and if i remember correctly, its an issue with the way your domain in Atlassian is setting up the timezone and the use of calendar in SLA.

If you want to jump on a call and show, i'm happy to try and assist.

[Hunter Wessinger]

The calendar is set up as follows: