What is the cause for "When SLA breach" Automation job not running at the right time?

[Hiroshi Nakasone]

I have created 2 Automation rules in JSM. The first rule triggers when SLA about to be breached in the next 15 minutes. The second rule triggers when the SLA has been breached.
Both of these rules will comment on the request of the warnings.

I have encountered errors where the first rule will trigger at the wrong time such as triggering 2 minutes after the ticket has been created. (image attached). Audit logs show no errors or conflicts and the SLA is set for 24/7 so there is no conflict with business hours. 

[Alina Kurinna _SaaSJet_]

Hello @Hiroshi Nakasone,

The issue you’re experiencing may be due to how Jira's automation rules interact with SLAs, especially when multiple triggers are close in timing.

In similar cases, automation triggers can get confused if:

• The ticket is repeatedly detected as nearing breach status in each automation cycle, significantly when conditions overlap;
• There's a lack of distinct criteria for each trigger, causing the rules to interact and potentially activate multiple times.

To address this, you could:

1. Double-check the "When SLA will breach in the next" parameter. It should be set to 15 minutes. Also, confirm that the rule isn't set to trigger on SLA start or pause events;
2. If multiple SLAs are applied to the issue, the automation might be triggering on a different SLA than you intended. In your automation rule, specify the SLA you want to monitor by adding a condition to check for the SLA name;
3. Adjust your automation rules to include conditions that prevent early triggering, such as checking the issue status or adding a condition to exclude newly created issues.

Also, you may try to use SLA Time and Report for Jira, which my team developed. This add-on can provide a more reliable solution for tracking SLAs. It includes detailed SLA tracking, breach alerts, and notifications without the need for complex automation setups.

Jira has certain automation limitations, so you might consider using our add-on to overcome these restrictions. This add-on offers flexible notification settings to inform your team about SLA statuses. You can configure notifications to be sent at specific times before an SLA breach. For example, if you have an 8-hour SLA target and want to receive a notification 2 hours before the deadline, you can set a notification to be sent at the 6-hour mark. This ensures timely reminders and helps prevent SLA breaches.

You can set up actions for breached SLAs, such as:

• Notifying specific users or groups in Jira comments or on Slack.
• Reassigning the issue to ensure visibility and prompt action.
• Escalating priority levels or changing the issue status to draw attention to SLA breaches.

Let me know if this helps!

[Mikael Sandberg]

Hi @Hiroshi Nakasone,

Welcome to Atlassian Community!

What goals do you have in your SLA? Without knowing what your SLA looks like it is hard to answer why the automations are triggering... 

[Hiroshi Nakasone]

Hi @Mikael Sandberg 

We have set our SLA goals based on the Priority field. We have 4 priority levels (critical, urgent, moderate, and low) and each have their corresponding times (30m, 1hr, 8hr, 24hr)The timer starts when the ticket is created. The only way to stop the SLA from counting down is assigning it to an agent or from a comment from an Agent. We have checked that the automation from Jira comment does not stop the SLA which is exactly how we wanted it to work. 

[Mikael Sandberg]

So I would start by looking at the actual SLA when you create a new request, does it get the right SLA goal? The next thing I would look at is the SLA when the automation is triggered, you can do that by using a web request in the automation to get the request with SLA information by using the Get sla information endpoint to get more information about it like elapsed time and remaining time and go from there.