Open vs Resolved: The SLA Reporting gap teams keep rediscovering in Jira

[#1]

Picture this: it's Friday afternoon. You open the SLA dashboard, scan the numbers, and close the tab feeling reasonably okay. The chart looks acceptable. No red flags. You head into the weekend.

Monday morning, the inbox tells a different story. Customers escalating. Agents overwhelmed. Tickets that should have been resolved days ago still sitting open – and some of them breached while you were looking at that calm dashboard.

This is not bad luck. It is a reporting gap that catches teams every single month.

I've spent a lot of time working on SLA dashboards and gadgets in Jira – in my earlier articles I covered how to build useful visualizations and what makes a support dashboard actually actionable. But the more I talk to support managers, the more I keep hearing the same frustration: the reports don't show what we think they show.

So let's fix that. This article is about the gap itself – what causes it, why it's so easy to miss, and four practical steps to close it.

What the gap actually is

Here's the thing: Jira is not broken. The platform can detect a breach while a ticket is still open. The SLA JQL functions breached(), completed(), running(), and remaining() all work correctly – you can write queries today that separate active breached work from completed cycles.

The gap is not a technical bug. It's a reporting interpretation problem.

When you open a standard SLA report in JSM and look at the "breached" count for the current period, that number can include older tickets that breached weeks ago and simply remained open. The report is not lying – it's just answering a more complicated question than you think it is. And when open breached cycles mix with completed ones inside the same view, the timing becomes difficult to interpret.

The practical result: a monthly summary that looks stable while your team is actively drowning in overdue work right now. Two very different realities. One chart.

Why most teams don't notice until it's too late

Most teams trust the default reporting layer – and that's a completely reasonable thing to do. If Jira tracks your SLAs, the report should tell you how you're doing. That's the assumption.

But the default report answers a narrower question than most managers assume.

A team lead opens the SLA chart and sees strong compliance. Meanwhile, the queue has multiple active tickets that already passed their targets. Or the report attributes older still-running breaches to the current period, making trend analysis confusing. It feels complete enough to trust. And by the time someone compares it to the actual queue – the mismatch has already affected staffing decisions, escalations, or customer conversations.

The worst part: this isn't a careless team. It's a team using the tool exactly as designed, just without knowing what the tool leaves out.

What a complete SLA report actually needs to show

Before jumping into the fix, it helps to agree on what we're aiming for. Here's a simple checklist:

✅ Open breached tickets active right now – not just the resolved ones
✅ Resolved breached tickets for historical analysis
✅ The exact date and time the breach happened
✅ Who was assigned to the ticket at the moment of breach
✅ Breakdown by priority, request type, and team
✅ Near-breach tickets that need action before they fail
✅ Trend view over time – not just today's snapshot

A complete SLA report also needs to serve two different audiences at once. Agents and team leads need operational visibility into what is breached right now. Managers need trends, ownership patterns, and a clearer explanation of where performance is slipping. These are different questions that need different views – and that's exactly what the four steps below are designed to build.

How to close the gap – step by step

Step 1. Find the hidden tickets with SLA JQL

The first thing to do is stop mixing open and resolved breached work in a single view. They answer different questions.

To find tickets that are breached right now and still open:

"Time to resolution" = breached() AND "Time to resolution" != completed()

To find completed cycles that breached before closing:

"Time to resolution" = breached() AND "Time to resolution" = completed()

And if you want to catch risk before it becomes a breach:

"Time to resolution" < remaining("2h")

completed() filters work items whose SLA cycle has reached a stop event. remaining("2h") captures work items that will breach within two hours – as well as those already past the deadline. Save these as separate named filters. This one step alone changes the reporting conversation, because you stop asking one overloaded query to answer everything at once.

Step 2. Record the breach moment with automation

The second problem is timing. Without a dedicated field, you have no reliable record of when a ticket crossed the line. That makes month-end analysis and root-cause reviews much harder.

Jira automation solves this cleanly. Here's the setup:

Create two custom fields:

• SLA Breach Date – Date Time Picker
• Assignee at Breach – User Picker field

Build the automation rule:

• Trigger: SLA threshold breached
• Condition: SLA name = "Time to resolution" (or whichever SLA you're tracking)
• Action 1: Edit work item → set SLA Breach Date = {{now}}
• Action 2: Edit work item → set Assignee at Breach = assignee smart value

For the User Picker field, use the assignee's account ID smart value in the automation action. This makes the field easier to reuse later in reporting and filtering – User Picker fields in Jira work with account IDs rather than display names.

Once this is running, every breach is stamped – regardless of whether the ticket is ever resolved. Now your reports can be built on the actual breach moment, not on how the SLA happens to appear in a later chart view.

Step 3. Build a reporting layer that covers both operational and historical reality

Once you can separate open breached work and capture breach timing, the next step is a reporting layer that reflects both what's happening now and what the trend looks like over time. This is where SLA Time and Report for Jira bridges the gap that native JSM leaves open.

SLA Grid – your operational view

The SLA Grid is the most direct way to see every ticket's SLA status in one place. It displays each work item with its SLA timer, time remaining until the goal is exceeded, elapsed time, assignee, and current status – all in a sortable, filterable table. Tickets already in breach show in red; those still within target stay green. You can customize and reorder columns to match your workflow, and sort by any dimension: key, type, assignee, or SLA timer value.

This is the view agents and team leads should have open during the day – not a chart, not a percentage, but a live list of what needs attention sorted by urgency. When the team lead asks "what are we behind on right now," the Grid answers that question directly, without any manual filtering or exports.

The Grid also supports export to XLSX, CSV, PDF, PNG, JPEG, and SVG, so sharing a snapshot in a review or attaching it to a stakeholder update takes seconds rather than manual formatting.

SLA Chart Reports – your trend and pattern view

Charts answer a different question: not "what's on fire right now" but "how are we doing over time, and where do we keep slipping?"

SLA Time and Report offers four chart types, each suited to a different level of analysis:

The SLA Statuses Pie Chart gives you the quickest health check – a color-coded snapshot of how tickets are distributed across Met, In Progress, and Exceeded at any given moment. It's the chart you pull up in a stand-up when someone asks "are we okay today?"

The Met vs Exceeded line graph shows the trend over a selected time period – how many SLAs were met and how many breached, week by week or month by month. This is the chart that tells the real story after a process change: did that new escalation rule actually move the numbers?

The Met vs Exceeded per Criteria chart adds a segmentation layer. You can break SLA performance down by assignee, priority, request type, or any custom field. This is where patterns become visible. If breaches cluster around one request type, one team, or one day of the week – this chart surfaces it. Without this level of breakdown, you're averaging out the signal and missing the actual cause.

The SLA Performance Comparison Chart gives you a percentage-based success rate view across multiple SLA configurations side by side – useful when you need to compare Time to First Response against Time to Resolution, or track performance across different projects in one view.

Gadgets – your always-on dashboard layer

Once charts are configured with the right filters and date ranges, you don't want to navigate into the app every time you need to check something. That's what gadgets are for.

SLA Time and Report lets you add three gadget types directly to any Jira Dashboard: the Pie Chart, the Met vs Exceeded chart, and the Met vs Exceeded per Criteria chart. You can add them directly from the Jira Dashboard gadget picker, or from inside the app by opening the chart you've already configured and clicking "Create Gadget" – the second method is faster because all your filters and settings carry over automatically.

Gadgets support automatic refresh every 15, 20, or 30 minutes, so the dashboard stays current without anyone manually opening it. This matters most for the operational layer – the view your team checks first thing in the morning to see what came in overnight.

Step 4. Split the dashboard into two layers people will actually use

A complete report is only useful if people see it without having to dig for it.

The operational view (for agents and team leads):

• Open breached tickets right now – SLA Grid filtered to breached() AND NOT completed()
• Near-breach tickets needing immediate action – Grid filtered to remaining("2h")
• Longest overdue items – Grid sorted by SLA timer ascending
• Workload by assignee – Met vs Exceeded per Criteria gadget grouped by Assignee

The management view (for managers and stakeholders):

• Resolved breach trends over time – Met vs Exceeded line chart by week or month
• Breakdown by priority and request type – Met vs Exceeded per Criteria gadget
• SLA success rate across configurations – SLA Performance Comparison Chart
• Repeat failure patterns – Met vs Exceeded per Criteria filtered to your most problematic request types

Two dashboards, two audiences. Agents get a live queue they can act on. Managers get a trend narrative they can trust – and share without exporting anything manually.

If you want to automate the management layer further, the Report Scheduler in SLA Time and Report lets you set recurring delivery of Grid report on a schedule, so month-end reviews don't require anyone to remember to pull the data.

What this looks like when it works

One pattern that comes up repeatedly with support teams: they keep missing monthly targets but can't explain exactly why. On paper, compliance looks stable. In practice, the team starts every Monday with a stack of tickets that breached late on Friday and sat untouched over the weekend.

Once they separate open breached work from closed history – using the JQL filters from Step 1 – the picture changes immediately. The SLA Grid shows exactly which tickets are red, sorted by how long they've been overdue. The Met vs Exceeded per Criteria chart reveals that a significant share of breaches comes from one specific request type submitted on Friday afternoons, when coverage runs thin.

That's a different conversation than "we have too many breaches." That's a scheduling and triage problem with a concrete fix. The team adjusts shift coverage, updates routing rules for that request type, and uses the Met vs Exceeded trend chart to track whether the change actually moved the numbers.

The improvement doesn't come from promising better service. It comes from finally seeing where the old promise was quietly failing.

---

Final thoughts

The SLA reporting gap is real, but it isn't mysterious. Jira can detect breaches while tickets are still open – the challenge is making that information visible in a way that actually supports decisions.

Once you separate open and completed breached work, stamp the exact breach moment with automation, build the right reporting layer with the Grid and charts, and split your dashboard into operational and management views – the story becomes much clearer. Not just "how many tickets breached," but which ones are breached right now, when they crossed the line, and what pattern they belong to.

SLA Time and Report for Jira brings all of this together in one place: the Grid for operational visibility, four chart types for trend and pattern analysis, gadgets for always-on dashboard monitoring, and the Report Scheduler for automated delivery – without needing to piece it together from separate tools or manual exports.

Have you run into this gap in your own Jira setup? Drop a comment below – I'd genuinely like to hear how your team handles it.