How to turn JSM SLA breaches into a service-credit figure (worked example)

Question

JSM tells you which requests breached an SLA, but not what that costs you under the contract. Most contracts credit on monthly availability or breach rate, so here is the method I use:

* Export the month's breaches. JQL: project = SUP AND "Time to resolution" = breached() AND resolved >= startOfMonth(-1) AND resolved < startOfMonth(). Export to CSV.
* Pick the measure your contract uses.* Breach rate = breached requests / total requests in scope.
* Availability = (minutes in month − downtime minutes) / minutes in month. A 30-day month has 43,200 minutes.

* Apply the credit tiers. Example contract: 99.9 % target, 10 % credit below 99.9 %, 25 % below 99.0 %. With 120 min of downtime in a 30-day month you get 99.72 %, so the 10 % tier applies. On a €4,000/month fee that's a €400 credit.
* Check the caps and exclusions: planned maintenance, customer-caused delay (the "Waiting for customer" status that pauses the SLA), and the monthly credit cap (often 25–50 %).
* Keep the evidence: the JQL, the CSV and the calculation, so the figure can be reproduced if someone disputes it.

How do you handle "Waiting for customer" time when you calculate credits? Do you exclude it or count it?

Orion · Answer

Thanks Josh, that's a neat way to make the cap enforce itself instead of relying on someone remembering it. One small thing for anyone copying the rule: in the Scheduled trigger, leave the option to only include work items that changed since the last run unticked. Otherwise the requests that have been sitting untouched in Waiting for customer, which are exactly the ones you want to move, get skipped. And agreed on the history point: the transition entries make the contract time easy to rebuild if a credit is ever questioned.

Josh · Answer

Hi @Orion , I can't point to a specific contract with that clause. But if a contract has one, you can enforce it in Jira Service Management, so the SLA clock follows the contract and nobody has to remember the cap.

The pause comes from the status: the SLA's time metric has "Pause on: Status: Waiting for customer". So restarting the clock means moving the request out of that status. A scheduled automation rule can do this:

* Trigger: Scheduled (for example daily), with the JQL project = SUP AND status = "Waiting for customer" AND NOT status CHANGED AFTER -5d
* Action: Transition the request back to your working status (for example "Waiting for support", if your workflow has that transition). The SLA then starts counting again.
* Optional: add a public comment telling the customer the request is active again, and why.

Change -5d to the cap in the contract. JQL relative dates count calendar time, not your SLA calendar, so a cap in business days needs a longer window.

There's a bonus for your evidence point: each restart shows up as a transition in the request history, so the contract time is easy to reproduce if a credit is disputed.

Orion · Answer

Thanks Sakina, that's a really good point. We see the same thing: whether 'Waiting for customer' time is excluded depends entirely on the contract wording, so it's worth reading the exclusion clauses before setting up the SLA calendar. In practice we keep two numbers side by side, raw elapsed time and contract time (with pauses), so both sides can see where the difference comes from when credits are discussed. Have you seen contracts that cap how long a ticket can stay in 'Waiting for customer' before the clock restarts?