How to audit and improve your SLA performance: a step-by-step playbook

[#1]

Your SLA dashboard is green. The monthly report went to management without red flags. And then, on Tuesday morning, a customer escalates, and you open the queue to find three high-priority tickets sitting in "In Progress" for days, all of them breached, all assigned to someone on leave since last week.

This is not a dramatic failure. It happens quietly, in teams that have configured SLAs, have reports running, and genuinely believe they have the situation under control. The problem is that monitoring SLA performance and actually understanding it are two very different things. Sometimes Jira shows you the timer, but not the story behind it, and that is exactly where SLA Time and Report for Jira start earning their place.

SLA performance needs to be audited, not just watched.

---

Why SLA performance can look fine while service quality still suffers

Most teams build their SLA setup once – during an initial JSM rollout – and then leave it mostly untouched as the team grows and workflows shift. Goals may no longer reflect how service actually works. Start and stop conditions may have been set up based on assumptions that expired long ago. Calendars may not reflect current working hours. And reports may be mixing open breached work with resolved history in a way that makes everything look more stable than it is.

Five root causes drive the gap between a green dashboard and unhappy customers: incorrect start/pause/stop logic; open breached tickets invisible as a live concern; one-size-fits-all goals that average out performance across priorities or teams; handoff gaps where ownership transfers and tickets disappear from everyone's queue; and bad reporting habits – drawing conclusions from a number that doesn't mean what you think.

---

The step-by-step SLA audit playbook

Step 1. 👀 Check what your SLA is actually measuring

Every SLA goal has a name, a target, and conditions – but the name rarely tells you whether it reflects your real service promise. What if most resolution time is driven by a third-party vendor, not your team? What if the real bottleneck is the L1-to-L2 handoff, which has no SLA at all?

List every active goal and ask: does this measure what we've promised, or just what was easy to configure? A team might consistently hit a 4-hour resolution SLA while first response quietly takes 2.5 hours. The numbers look fine. The customer experience is not.

Step 2. 🧐 Audit your start, pause, and stop conditions

A single misconfigured condition can distort SLA performance across hundreds of tickets without anyone noticing. Three common problems: the clock keeps running while waiting on the customer, so breach rate measures their slowness rather than your team's. The clock pauses in a status that isn't a real waiting state, making the team look faster than it is. Or the stop condition fires too early – at "Pending verification" rather than actual resolution – making breaches structurally impossible.

Take a sample of 20–30 recently resolved tickets and trace the SLA timeline manually against the status history. If the timer behavior doesn't match what your team actually did, the conditions need adjustment.

Step 3. 🤝 Separate open breached work from completed SLA history

This is the reporting mistake that catches teams every month.

The "breached" count in a standard JSM report can include tickets that breached weeks ago and are still open. The result is a monthly summary that looks stable while the active queue is quietly full of overdue work. The fix is two separate JQL filters:

For what's actively breached right now:

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

For historical analysis:

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

These answer different questions and should never be read as one number. For teams that want a live view without assembling this from JQL manually, SLA Time and Report for Jira provides an SLA Grid that does exactly this – sortable, filterable, and color-coded by breach state.

Step 4. ⚙️ Segment performance by priority, request type, and team

Averages hide problems. Averaging routine service requests and critical incidents together produces a number that's misleading for both. Break your SLA data into segments – by priority, request type, squad, or time of week. One specific request type may have a breach rate three times the average because it flows through a different approval process nobody connected to the SLA timeline. Segmentation turns "we have too many breaches" into "we have too many breaches on this specific type of work, and here's why" – which is the conversation that leads to actual fixes.

Step 5. 🧑‍💻 Review handoffs and ownership gaps

Many SLA misses happen between teams, not inside one team. A ticket handled well by L1 gets escalated to Engineering. The support SLA pauses in "Pending Engineering" status. But there's no SLA measuring how long it sits before Engineering picks it up. Four days pass. The support SLA looks fine. The customer experience is not.

Look for workflow statuses that represent transition points – "Escalated," "Pending L2," "Awaiting Engineering," "With Vendor" – and ask: is there any goal measuring the time a ticket spends here? If not, you have a handoff gap. This is exactly what OLA (Operational Level Agreement) configurations are designed to address.

Step 6. 📅 Verify calendars and working hours

Calendar misalignment is one of the quietest sources of inaccurate SLA data. If the calendar doesn't match how your team actually operates, the SLA either runs when no one is working or pauses when people are available.

Common findings: a team switched to rotating shifts but the SLA calendar still reflects 9–5. A global team added APAC coverage but the clock runs on Central European Time, so tickets submitted Friday evening in Singapore breach over the weekend while the calendar says the business day has barely started. Check the calendar assigned to each active SLA goal and compare it to actual coverage.

Step 7. 📊 Turn findings into automation and a repeatable review rhythm

An audit produces findings. Findings without action produce nothing. Each gap should translate into a specific change to conditions, workflow, calendar, or how the team monitors SLA status.

If tickets breach over weekends unnoticed, set up an automation that checks for approaching SLAs on Saturday morning and posts to a duty Slack channel. If high-priority incidents are slipping, add a pre-breach notification at 50% of the target – not 90%, which is almost always too late. If a handoff gap exists, automate a ping if a ticket sits in "Pending Engineering" for more than one business day without an assignee change.

SLA Time and Report supports this with configurable pre-breach and breach alerts tied directly to SLA state – useful when native JSM automation becomes too rigid for the workflow logic you actually need.

Make this repeatable. A weekly queue review covers what's breached now. A monthly trend review tracks whether things are improving. A quarterly SLA logic review checks whether goals, conditions, and calendars still reflect how the team actually operates – the review most teams skip, and the one most likely to catch slow configuration drift before it shows up as a customer complaint.

---

Final thoughts

Real SLA improvement isn't just fewer breaches. It's cleaner reporting people trust, fewer surprise escalations, faster reaction before breach, and visibility that closes handoff gaps before they reach customers.

Native JSM handles the fundamentals well. As workflows grow more complex – multiple queues, cross-team handoffs, global schedules, segmented reporting needs – teams often need more. That's where SLA Time and Report adds value: live operational visibility, flexible alert logic, and reporting that separates the questions worth separating.

If you work through this audit and find specific gaps in your own setup, I'd genuinely like to hear about it. The most interesting SLA problems usually turn out to be visibility or workflow problems in disguise – and those are worth talking about.