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.

[Alina Kurinna _SaaSJet_]

Hi  @Laura Jiménez Goicoechea ,

Based on what you described, I would first check when the Tipo field is populated for the issue.

If your SLA goal depends on Tipo, but this field is filled later by automation, the issue may not match the SLA goal at the moment when the SLA is expected to start. That can create a confusing situation: later, the issue matches the JQL in search, but the SLA was not applied when the issue was created or when the SLA conditions were evaluated.

A few things you can test:

• Create one test issue where Tipo is already set at creation.

• Create another test issue where Tipo is added later by automation.

• Compare whether the SLA appears in both cases.

• Check whether recalculating/reconstructing SLA data changes the result.

• If possible, make sure the field used in the SLA goal is set before the SLA should start.

If your team often works with SLA rules based on custom fields, automation, request types, priorities, or different workflow conditions, you may also consider using a Marketplace SLA app as an additional SLA tracking layer.

For example, SLA Time and Report for Jira lets you configure SLA timers with flexible Start, Pause, Stop, and Reset conditions. You can build SLA logic around Jira fields and custom fields, define different SLA goals for different cases, and track the result directly on the issue. This can be useful when native JSM SLA configuration becomes hard to manage because the SLA depends on field values, workflow changes, or more complex business rules.

The app can also help with visibility after the SLA is configured: teams can use SLA Grid reports, SLA charts, Jira dashboard gadgets, and alerts to see which tickets are on track, at risk, or already exceeded. So instead of only checking whether an SLA appeared on one ticket, you can monitor SLA performance across projects, teams, or specific SLA goals. 

It will not “fix” a native JSM SLA configuration issue automatically, so I would still start by checking the timing of the Tipo field and the SLA goal logic. But if this type of setup is common in your project, a more flexible SLA configuration and reporting tool may make the process easier to control.

I hope I could help. Regards!

[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

[Laura Jiménez Goicoechea]

Hi @Marc -Devoteam- 

Thanks for the quick reply! Issues are created with Minor priority as default, but we were thinking that the custom field "Tipo" is set by an automation that runs once per day, so I'm thinking that might be the issue.

In any case, even if I recalculate the SLA in the issue, it still does not appear.

We'll carrying some tests to confirm if this is the issue, and if so, I'll come back and let you know.

Thanks again for your insight!