SLA not appearing on some tickets despite matching JQL

[Laura Jiménez Goicoechea]

Hi everyone,

I’m experiencing a strange issue with a "Time to First Response" SLA in Jira Service Management Cloud. The SLA for Time to Resolution appears, but the Time to First Response doesn’t appear on certain tickets, even though they seem to meet all the JQL criteria.

---

Our configuration

Time to first response

• Start condition: Issue Created.
• Pause condition: Status: Pending or Status: Waiting for customer.
• Stop condition: Comment: For Customers, Entered Status: In Progress, or Resolution: Set.
• JQL Goal:

  issuetype = Support AND ("Tipo[dropdown]" = Abono OR "Tipo[dropdown]" = Deuda) 

  with specific targets for Priority (e.g., Minor = 8h).

Time to resolution

• Start condition: Issue Created or Resolution Cleared.
• Pause condition: Status: Pending or Status: Waiting for customer.
• Stop condition: Resolution: Set.
• JQL Goal:

  issuetype = Support AND ("Tipo[dropdown]" = Abono OR "Tipo[dropdown]" = Deuda) 

  with specific targets for Priority (e.g., Minor = 8h).

---

Issue with Time to First Response Missing

• issueType = Support
• Tipo = Abono
• Priority = Minor

---

JQL check in the advanced search

---

Reporters are customers and most of them already have a public comment from one of our agents.

I'm sure there must be something wrong with the configuration, but I don't see where the error might be, so I'd appreciate any insights on this.

Thank you very much in advance!

[Andrea Robbins]

This is a major gotcha that many JSM users do not know about! Let me explain the concept:

SLAs are set at at the events under, "Start counting time when..." - the problem is if any priority or other updates occur, it does NOT recalculate.

You have three options to recalculate:

1. Non-destructive recalculation

Triggered automatically whenever SLA configuration is changed, applied to all open issues.

The non-destructive recalculation is used as a last resort when the customers have the wrong SLA state or value for specific Jira issues.

2. Graceful destructive recalculation

Restting SLA for a single issue

Jira Admins can use a"Recalculate SLAs" buttonin the SLA panel to re-run the SLA calculation for that issue based on the current SLA configuration — no API calls or automation rules needed.

Triggered from a debug REST endpoint(force=false)

The graceful destructive recalculation will calculate a new SLA value and compare the timeline with the previous SLA value to see if the event order is wrong. If it is, it will sort the timeline events by their timestamp and update the SLA value with the new timeline and new state and value. It is destructive, as it would re-create the ongoing data from a new timeline. Internally, it uses the same algorithm as the normal, non-destructive recalculation to calculate the new timeline.

3. Forceful destructive recalculation

Triggered from a debug REST endpoint(force=true)

The forceful destructive recalculation would, again, calculate a new SLA value. But in contrast with graceful recalculation, it won’t perform any checks or try to repair the timeline. Instead, it would simply replace the old SLA value with the newly calculated one.

Quoted from: https://support.atlassian.com/jira/kb/resolve-wrong-or-missing-slas-in-jira-service-management-cloud/

TLDR; either update the SLA (not really an option imo because you can't update the SLA every time a ticket is created. Ridiculous option imo.) or set up an automation rule to hit this endpoint (using the send web request):

https://mysite.atlassian.net/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct?force=<true or false>

I always use true because I want to recalculate the SLA as the ticket was always set to the changed priority, but false allows you to reset the SLA only from the time the priority changed, so if set to false, if default priority was P3, which had a 5h goal but was updated to P0, it would calculate priority during the time it was P3 as P3 plus the time it was P0. If it was true, it would treat it like it was always set to P0.

The linked document will give you step, by step instructions.

[Marc -Devoteam-]

Hi @Laura Jiménez Goicoechea 

As the SLA's are bound to the priority field being set, is this field set on creation?

This seems to be the problem, as there is no priority set, there is no target, so the SLA is not triggerd.

So if the priority field is set later then on creation, the SLA is not triggered.

You could add issue updated as a trigger, or set a default priority on each created issues