Long email delay with Jira service management (cloud)

[Greig McArthur]

We recently started trialling a project in Service Management (cloud) and are seeing multiple issues with email including huge delays - many hours - in email notifications being delivered.

For example, in a test issue I set the status to "Declined" at 9.21am, however the email notification to the Reporter didn't get sent until 2.23pm.  

Is this normal?  Should we expect delays of this length?

I'll tackle the other issues separately, but is there any settings etc I can adjust here that I am missing?  We are seeing this across many different email domains used for testing (our own as well as gmail etc) so it is not related to the recipient.

Any advice/troubleshooting I can follow would be most welcome.

[Jack Brickey]

No you should not see this sort of delay. Generally I see < 1min. When you say the email didn’t get sent until 2:23 how are you determining this. Please keep in mind that the time the email is received by the customer does not equate to when Jira actually sent the email. There could be something delaying the receipt within the network path. Can you add a watcher to the email that is part of your group and see when they receive the notification. If you have multiple recipients and are seeing long delays on notifications then that might point to your Jira instance.

[Greig McArthur]

Thanks for your response.  We can check the logs of when the incoming mail was actually received by our server, so we get very accurate times of receipt (for accuracy, I would say the receipt time was 2.23pm, we don't know when service desk tried to send it, but we are confident there is no delay in our servers).

We have since replicated the problem with a number of different email addresses and domains and the result is currently the same - emails from Service Management are taking many hours to arrive.

Other emails which come from JIRA itself are arriving immediately - its only an issue with Service Management.

The instance is the atlassian could - we don't run our own instance.

[Jack Brickey]

I have never experienced this at all. I assume you are using OOTB notifications and not any addon. Is your JSM instance part of your JSW instance or independent? If not consider adding JSM directly to your JSW instance.

[Jens B]

I face the same issue with Service Management.

Did create a brand new instance with a default "General service management" project. Customers are added through REST, also added to portals, and organizations.

Never seen such an issue with email delays before.

[Jens B]

https://jira.atlassian.com/browse/JSDCLOUD-5459

[Jens B]

This is what Atlassian technical support gets from the log files:

421 421-web.de (<mxN>) Nemesis ESMTP Service not available
421-Service unavailable
421-Reject due to policy violations.
421 For explanation visit https://web.de/email/<hash>?ip=a.b.c.d&c=poli 616f90f36f61113f8d81

I receive those emails, but it takes hours.

Unfortunately, the link to the explanation got removed, and web.de 's support team only is reachable through a ridiculous expensive (a few Euros per minute) support hotline. I am not going to call them.

Probably @Greig McArthur gets access to the log file of his mail provider?

[Jens B]

@Greig McArthur 

The issue is resolved. Beneath Atlassian's reply:

We checked this internally and we came to know that there was an incident at SparkPost (which is our ESP).

https://status.sparkpost.com/history

As per their status page, the issue is now resolved and you shouldn't be facing any delay. Please feel free to reach out to us if you've any further queries on this.

[Jack Brickey]

Excellent thanks for adding the details to this post.