This SLA issues were fixed about 2 days back through a case I reported. Finally they figured the issue.

checked audit logs today, this is finally working on my site

Hey folks, we are still experiencing the bug too.

How do we know if the fix has been rolled out to our site? Because we are still experiencing the bug and you announced the fix was done more than a month ago.

Hi @Manas Shukla, thanks for helping on this one

Could you give an update on this matter, where you are with the roll out of the fix?

One of our customers reported errors on 28th of June, see below for errors details, this was happening few times both on 27th and 28th of June.

• Error running JQL search to find issues breaching SLA:

"(cf[10057] > 0 and cf[10057] < 7m) AND (project in (10002))" - NoHttpResponseException: The target server failed to respond

• Error running JQL search to find issues breaching SLA:
  "(cf[10067] > 0 and cf[10067] < 7m) AND (project in (10002))" - SocketException: Socket closed

Have not seen similar issues/errors recently, looks good in the audit logs.

Thanks in advance!
 

@manas - I see it as an alert that the automation failed "The automation rule (XX) SLA for first response will breach in 1hr just failed with an error on your Jira instance" 

To be honest I don't normally see the socket error, usually I get nothing at all apart from the following in the rule audit log, which can happens tens of times a day.

66601fb371e4  eb56b1b81ef9 5484d444fc52  Do you still see the socket exception issue for your SLA/ automations?

Product Update - 28th June 2023

Hi folks,

Long term fix for this issue has been implemented and will be gradually rolled out in the coming weeks.

Meanwhile, we are looking into issues that some customers have reported on this ticket regarding automation erroring out since the last couple of days

Agree with Manu - suggest something changed as this has only become an issue for us since the end of last week, when the automation has been in use for over a year.

Our automation to alert when issues are about to breach SLA for first response are throwing errors, although, the automation appears to still be working. I'm relying on a daily report to check issues (that have breached first response SLA), daily, and it's time consuming!

Had a whole bunch of my SLA related rules fail this morning around 9AM...

Error running JQL search to find issues breaching SLA:
"(cf[10049] > 0 and cf[10049] < 7m) AND (project in (10008))" - SocketException: Socket closed

Any update on this?

As of yesterday our environment has started encountering this error as well. Maybe it's useful to check our environment to see what triggered the issue as before we had no such issue

Any update? Thank you! 

Is there any update on this ?

Any update? Thank you. Yatish

I've not seen this issue (yet!), but if there is something I want to know if an automation has done successfully, and it's that critical, I'll  add a custom field (checkbox) that gets set as true when the automation I am trying to run completes its work successfully. If the automation fails to execute when the SLA is breached, the field will be false still, so I can run a daily scheduled task to find everything with breached SLA and this field set to FALSE and either fix them up manually (and squash any bugs in my automations!) or have the automation re-run the thing it was supposed to do.

Heck, if you want to get more fancy, chuck in a number field, and have it iterate that number every time there is an error - then you can have it retry the automation, and if it fails enough times, you can have it create an alert somewhere else to check things.  ¯(ツ)/¯ 

I've had this problem for almost a year now!
The last time I contacted you, I received the same response.
It is not possible that your development team has been working on this error for so long and has not been able to find a solution!

Unbeliveable!

Can we get an ETA on this fix?  It is causing us issues because we cannot support our SLA breach needs and send emails to appropriate folks using the legacy automation rules.  It's heating up with management on how we can solve for this issue.

Would be great to have a short update on the ETA for the fix.

I've seen the Unauthorized error also. Seems intermittent.

It also seems like a very intensive process to query the status of that SLA evrey 7m... Is this being reworked?

Any update on the development / ETA?

+1 PCS-161021

Weak development of this function if it just randomly fails to run due to a time out.
Watching this as we have many SLA based rules.

My SLA related rules started to get  Unauthorized error instead of Socket errror . 

Any Update ?

Action details:

Error running JQL search to find issues breaching SLA:
"(cf[10083] > 60m and cf[10083] < 67m) AND (project in (10167))" - Unauthorized

For us the workaround provided is not working. We are waiting for updates.

This issue has affected all of my projects for (six!) months now where I've had to manually update tickets and project workflows. Not to mention the additional manual work my Helpdesk team now has to do. Please bump to a higher priority. Without successful automations, this occupies nearly all of my working time.

We 'are waiting fix for this bug ..

Error running JQL search to find issues breaching SLA:
"(cf[10080] > 90m and cf[10080] < 97m) AND (project in (10167))" - SocketException: Socket closed
 
Could you please make it higher priority ?
Thanks in advance .

Just got a surprise that one of the SLA indicators was not breached. Too good to be true  
Now I'm forced to review a few thousand tickets manually. The new year is off to a great start!

Please Atlassian, such a bug should be a high priority!

For us the workaround provided is not working. 

Need again a fix. After having issues with Confluence  

Bumping this issue. We experienced and issue with SLA based automation firing off. Is there an ETA for this issue to get resolved?

 A number of my rules are also affected by this...hoping this is fixed soon.  Thanks

Yesterday I received a nice e-mail from Atlassian, telling me how to deal with SLAs  

I think it would help to get this fixed first, before telling Service Managers how important SLAs are

Header: On the clock: SLAs matter because time does

https://www.atlassian.com/itsm/service-request-management/slas?utm_source=cs-email&utm_medium=email&utm_campaign=P%3Ajira-service-management%2AO%3Acs%2AC%3Acampaign%2AW%3A1b_cta_button%2AI%3Asla-all-day_EML-14101&jobid=105829334&subid=1593711566&send_date=12/8/2022%2AE%3Acloud%2A_EML-14101&jobid=105829334&subid=1593711566&send_date=12/8/2022

Anyway. I am happy to see that it is ready for development now. Looking forward to receive some good news in the new year

Meanwhile, I've gotten used to the automation rule failing at irregular intervals 3x per night without an issue being involved.

What I noticed today is that the rule has now been automatically turned off by Jira and it accordingly failed to work on a real case today.I have not received a message that this rule and two others have been disabled.

If rules suddenly stop working, I would check to see if they have been disabled.

Product Update - Nov 2022

Hi folks,
 
This request has been prioritised and would soon be picked up by our development team. Once we have a timeline, I'll update it here.
 
If you are facing difficulty setting up SLAs (due to limits, conditions, goals etc.) and would be interested in talking to product team and provide feedback, you can book a slot using this link.
 
https://calendly.com/manas-atlassian/30-min-customer-meeting 

Another error message:

Error running JQL search to find issues breaching SLA:
"(cf[some label id] > 0 and cf[some label id] < 7m) AND (project in (some project id))" - Could not get a bearer token

I have to agree with Tasso Henke. Also I think there should be a discount of 80% for Jira Service Management licence because it´s not useable for professional service management. We have additional manual effort to SLA check what the program/automation should do what we pay for. It´s time to check to take legal steps.

LONG TERM BACKLOG ?

This has to be a joke. This is about a central aspect of service management, namely compliance with SLAs.

Do you understand that companies that provide support for customers are contractually bound to comply with SLAs? So how to comply if there are no warnings? 

Are we allowed to charge you resulting contractual penalties in the future?

I am very disappointed and we will have to look for a real service management tool if this stays in backlog.

LOL the work around has been removed:

Legacy automation is being superseded by automation

Legacy automation is not available in new Jira Service Management sites. 

Any updates on this?  My automation is failing randomly and thus I have hundreds of tickets that should be CLOSED, but are still just Done.

I am on Cloud and I do not see the Legacy automation options anywhere.  The workaround is not an option for me.

Please advise as to another workaround for Cloud installations.

This is actually pretty surprising. I just learned about this because our new SLA automations are failing to fire and it led me here. A company offering a feature that may randomly fail without warning as expected behavior is pretty wild to me.

It would make way more sense to just remove the trigger since it's clearly broken, until you've decided it's worth fixing. But leaving it in place and then adding a small warning at the top that says "this thing may not work as intended randomly" is pretty crazy.

Admittedly I didn't even read the warning at the top because I assumed it was just alerting me to some crazy edge case where SLA triggers wouldn't work that surely didn't apply to my simple use-case. But no, it's not an edge case at all. It just randomly doesn't work by default.

Any updates?

Hi, any updates on this? Thanks

Any update on this, please? Thank you.

Is it possible to give this a higher priority? Legacy Automation is not an available setting/option in some cloud deployments. As such the workaround is not a viable solution for some customers. This is a critical bug as SLA's are integral to IT HelpDesks and it is confusing that it is taking so long to resolve something so impactful.

I have just found out this bug, which on a product which costs many thousands dollars each year, should really not happen.

I am also baffled that a bug of this impact is only a medium priority which will maybe be fixed next year.

The suggested "workaround" is indeed VERY limited, since it does not allow to specify custom interval, nor you can perform some other actions which you would be able to perform in the newer automation; for example, I didn't find an option to send a slack message, or to send an e-mail to a custom e-mail address.

Any chance this can be a priority on the backlog since the workaround is no longer viable? 

New instances don't offer Legacy Automation anymore.

Any update on this issue. 

Legacy automation is not a great workaround as the SLA breach triggers do not offer the same amount of flexibility i.e. the options are 30/60 mins from breach or breached. New automation allows far more options around the triggers i.e. days/hours/mins until breach or after breach but now no longer works!

The only other option is using time in status triggers on legacy but again this isn't the same as using SLA's allows you to define calendars and business hours etc.

Atlassian really need to fix this...long term backlog is not good enough. 

Any chance this can come out of the backlog since the workaround is no longer viable?

Any reply would be nice. 

Thanks

Is this still a bug? Legacy Automation was removed 

https://community.atlassian.com/t5/Jira-Service-Management/Legacy-automation-is-being-superseded-by-Automation-in-Jira/td-p/1775698

Hence your workaround is not available anymore?