SLA missing on new tickets despite matching the START condition and JQL goals
Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.
Summary
Find out why SLAs might be missing in some issues, even if they meet the SLA START condition and match the JQL in the SLA goals.
What can cause the SLA cycle to break?
This can happen when the STOP condition is met before the START cycle is completed.
Using an example, imagine your project has a Time to First Response (TFR) SLA configured where:
- All goals that have a time target require the "Text Field" is not empty.
- This SLA starts when the issue is created.
- This SLA stops when an agent replies (adds a public comment) to the customer.
An issue is created where the Text Field is empty. It will fall under the 'remaining issues' condition of the SLA, with no time target, so the issue will not have a TFR SLA.
Then, these events happen in order:
- An agent adds a public comment to the issue.
- A value is set for the Text Field.
This sometimes breaks the SLA's cycle, as the STOP condition of the SLA (public comment added) was met before the START condition (issue where the text field is not empty).
Fix it by recalculating the SLA
Recalculating the inconsistent cycle should fix it. You can force a recalculation an SLA following the steps in: Resolve Wrong or Missing SLAs in Jira Service Management Cloud.
How do I prevent this?
Ensure your SLA configurations align with how your agents work.
- Avoid the "Issue Created" in START condition: If there is a risk the STOP condition matches as soon as the ticket is created, use a different START condition to the SLA.
- Ensure the STOP condition is not met BEFORE the correct SLA is applied: Review the STOP conditions carefully. For instance, if there is a risk of public comments being added right after issue creation, consider creating a workflow status that indicates a response has been given to the customer. Use this status as a trigger in the STOP condition instead.
How do I identify if this is the problem with my SLA?
If you access the API endpoint https://yoursite.atlassian.net/rest/servicedesk/1/servicedesk/[PROJECTKEY]/sla/debug/issue/[ISSUEKEY]/metric/300/data, you see a response for the affected SLA like:
{
"date": 1733303061863,
"dateString": "2024-12-04T09:04:21.863Z",
"types": [
"STOP"
]
}
]
},
"ongoingSLAData": null,
"completeSLAData": [],
(...)
"customFieldName": "Time To First Response",
The SLA information has a STOP dateString defined, meaning the SLA cycle is complete, the completeSLAData is empty
Other issues with SLA cycles
There are other reasons why an SLA may be missing or broken. The following pages might further help you:
- How to troubleshoot common issues with SLAs?
- Measure Time to first response SLA for reopened issues in a JSM project
- Breach time not found in SLAs
We have known bugs on SLAs that may affect your experience using JSM:
- JSDCLOUD-5171 - SLA is not started when starting and pausing/stopping the SLA at the same time
- JSDCLOUD-9096 - Editing or removing the options of a field that is part of an SLA goal query will prevent the SLA from being updated
- JSDCLOUD-3562 - SLA disappears if the "Stop" condition refers to a past event
- JSDCLOUD-9874 - SLA isn't stop/paused if the condition is moved from Start to Stop condition