SLAs in Jira Service Management that your team actually meets

Why SLAs turn red even though the configuration is right

At MESKRU we regularly see Jira instances where the SLAs are set up cleanly and are still missed. The reason almost always sits outside the system: an SLA goal is set without creating the organizational conditions needed to meet it. Four gaps are typical:

• Nobody owns the service. A queue without a responsible person or team is not a service, it's a mailbox. When the clock runs out, nobody feels responsible.

• The goal doesn't match capacity. Four hours to resolution sounds good, as long as nobody works out how many tickets arrive, in what time, for how many people.

• There is no cover. Vacation, illness, end of shift: when the one person who knows the topic is out, the ticket stalls and the clock keeps running.

• Escalation means chasing after the breach. Whether an SLA was breached is in the report. Who is informed beforehand and who may step in is defined nowhere.

None of these gaps can be closed with another SLA condition. They have to be settled and tested in the organization first. Then they can be mapped into the system for good.

Four questions before an SLA goal goes into the system

1. Who owns the service? A person or team that answers for meeting the SLA and knows the numbers.

2. Is there enough capacity, including cover? The goal has to match ticket volume, staffing and service hours, not wishful thinking.

3. What happens before time runs out? Who is informed when, and who has the mandate to reprioritize or get help?

4. How is the SLA documented and reviewed? Where can customers and the team read it, and when do you look at the numbers together?

Only once these four answers are in place is it worth entering the goal in Jira Service Management.

What the clock in Jira Service Management measures

An SLA in JSM consists of conditions, goals and calendars. Knowing the rules behind them helps you avoid the most common measurement errors:

• Start, pause, stop. The clock starts as soon as one of the start conditions is met and stops as soon as one of the stop conditions is met. Pausing is optional; a typical case is waiting for the customer to respond.

• Goals are checked from top to bottom. Each goal uses JQL to filter which tickets it applies to. The order decides, and at the end there is a catch-all goal for all remaining tickets. If a ticket matches no specific goal, it lands there, possibly with no target time.

• Calendars define the time. Calendars set working hours and holidays. Outside them, the clock stands still. An SLA without a suitable calendar measures around the clock.

Atlassian itself names two traps: if the start and stop conditions are identical, a ticket can get several SLA cycles. And if the stop condition is met before the cycle has properly started, the ticket ends up without an SLA. Both distort your reporting without anyone noticing.

Escalate before the breach, not after

An escalation that only kicks in after the breach just documents the problem. JSM has the building blocks to react earlier:

• A queue for upcoming breaches. JQL functions for SLAs let you filter tickets by remaining time, for example "Time to resolution" < remaining("2h"). The team then sees what is about to tip over, not just what already has.

• Make breached SLAs visible. breached() finds tickets whose last SLA cycle missed its goal. That belongs in the service review, not in a blame discussion.

• Notify the right person. Jira automation can react to SLA thresholds. What matters is the recipient: the person with the mandate to step in, not the whole team.

The technology is the smaller part. The bigger part is agreeing who may do what when a warning comes in. These paths must be defined and tested in advance, then configured in the system.

Derive SLA goals from the service, not from the form

Many SLA goals depend on priority, and the reporter often picks the priority. So a guess in the portal decides how fast you have to deliver.

It is more robust to derive the goal from the affected service. With Assets, SLA goals come from object attributes such as the service tier. A production system and a test system then never share the same clock. We describe how to build such a model in Modeling Assets in Jira Service Management .

Look at the numbers together

An SLA whose numbers nobody discusses regularly loses its effect. In the service review, the team assesses the metrics, looks for patterns and adjusts processes: Which tickets miss the goal? Is it capacity, missing information or a handover? And does the goal still fit the service?

Goals are allowed to change. New services, growing teams and new requirements belong in the same meeting.

Five questions for a self-check

1. Can you name a person or team responsible for every SLA?

2. Is the goal derived from ticket volume and staffing, including cover?

3. Does your team see upcoming breaches before they happen?

4. Is it defined who may step in when a warning comes in?

5. Do you discuss the SLA numbers regularly and adjust goals or processes accordingly?

Every no is a reason an SLA turns red, no matter how well it is configured.

How we help

At MESKRU we first review the technical setup of Jira Service Management. After that, the focus is the operating model: defining services and ownership, developing escalation paths and SLA concepts, and supporting the rollout. For existing environments we offer health checks in which we find the biggest lever together with your teams.

More on our Service Management & Collaboration page. For background on the operating model, see Jira Service Management as an operating model .