Summary

The Jira application has a flexible built-in facility for sending email notifications under various conditions. This guide is meant to help troubleshoot when email notifications are not being received.

No email notifications are being received by anyone (or are received with a very long delay or hours/days)

• Ensure you've correctly configured an SMTP server. Send a Test Mail inside the SMTP server configuration setup screen. Note any error that is returned from the test.
• Inspect your Mail Queue under ⚙ > System > Mail Queue. Check if emails are piling up in the Mail Queue or the Error Queue and if you can flush it manually from the UI.
  • If emails are piling up in the Error Queue or are listed in the Mail Queue with the pink color.
    
    • Then it means that the Mail Queue Service is unable to send the notification email via the SMTP server (for various reasons).
    • In such case, you can refer to the section Troubleshooting SMTP mail server issues of the KB article Troubleshooting slow/stuck notification issues in Jira/Service Management Server/Data Center.
  • If emails are piling up in the Mail Queue with the white color, and if it is possible to flush the Mail Queue from the UI manually.
    
    • Then it means that the Mail Queue Service might be stuck (for various reasons).
    • In such case, you can refer to the section Troubleshooting Mail Queue Service issues of the KB article Troubleshooting slow/stuck notification issues in Jira/Service Management Server/Data Center.
• Go to the page ⚙ > System > Batching email notifications, and check if batching is enabled. If disabling batching resolves the notification issue, then it is possible that the service responsible for the batching of Jira Notification was stuck.
  • in such case, you can refer to the section Troubleshooting Jira Batched Notification mail issues of the KB article Troubleshooting slow/stuck notification issues in Jira/Service Management Server/Data Center.

Email notifications are not being received by a specific group of people/person, or from specific Jira issues

• Check if the My Changes option in the user's profile is Notify Me. The default value for this property for all users can also be set under Administration > User Defaults.
  
• Check the project permissions under the project's permission scheme. Users must have Browse Project permission for the project to which the issue belongs. If you're using Issue Security Levels, ensure they are members of any Issue security levels that have been applied to the issue.
• If these users did not receive a specific workflow transition notification, they must note that their post-function triggers notifications in a transition. In such a case, you must review the workflow configuration, check which events are fired for each transition, and ensure that these events are configured with the correct recipients in the notification scheme configuration.
• Check if the user who is not receiving notifications possesses a Jira Software and/or Jira Service Management license (depending on the project type of the issue in question). This is identified in the user's profile under Jira Administration > User Management > Users > Search for user > Click on display name hyperlink > Verify if Jira Software/Jira Service Management checkboxes are selected.

A Jira user received a notification from a ticket while this user was not expecting to receive it

Sometimes, a user gets a notification email from the Jira application, but this user was not expected to receive it. To troubleshoot this issue, a few points to check include:

• Checking if the Insight application is installed in ⚙ > Manage Apps > Manage Apps.
• Checking if the user is a component lead within the project.
• Checking if users are configured in ⚙ > User Management > Users (it could be that a user is configured with an email address that belongs to another user and that notification emails were sent to that other user).

The content of the email notification is wrong

• If the content of the notification refers to an invalid or non-existent issue, then the notification may be coming from another source (that is, another Jira instance, separate from the problematic one). This situation can happen when you restore an XML backup of your production Jira application instance into a development/test server or if another Jira instance is connected to the same mailbox as the problematic one. The development/test/another Jira server application then sends notifications in addition to your production instance. Please see this guide on Disabling email sending/receiving for a Development/Test Jira instance.
  To verify if the notification is coming from another Jira instance:
  - Check the source of the incorrect notification email for the 'X-JIRA-FingerPrint' header, then locate the 'correct' notification, find the same header, and compare the two - they have to be identical.
  - If X-JIRA-FingerPrint is missing (and that could be possible as some email servers strip what they consider unnecessary headers), look for the 'client-ip=' header and compare the same to a good notification. If the IP addresses differ, the notification will likely come from another Jira instance. To identify the public IP address of the Jira server or cluster, you'd either need to reach out to your network administrator or use 3rd party free services like What is my IP Address, which can also be used from the command line via a curl command (for example, 'curl ifconfig.me').
• If users receive messages in HTML or Text and wish to change this preference, have them change this property in their user profile under the Outgoing email format.
• If the URL links inside the notification content point to the wrong site, check your base URL property under Administration > General Configuration.
• If the FROM: header of the mail being received is not what you've configured under Administration > General Configuration > Email from, check to see if the Project's Mail Project setting is set. It will override the global setting.

Duplicate notification emails are being sent from Jira applications

• Check the atlassian-jira-outgoing-mail.log file to see if any SMTP timeouts are occurring, as in our Jira notification emails fail to be sent due to read timed out error KB article. Jira applications may successfully communicate with the mail server, send the email, and then time out while waiting for the response. As the SMTP server has not received a successful response, it will attempt to resend emails until it receives them.
• If you have any third-party mail apps, please disable them and retest the behavior to see if the problem can be isolated further.
• Check if, in addition to the seeded post-function from the "Create" transition, a third-party app triggers the "Issue created" event. If that's the case, remove the "Issue Created" event trigger from the third-party app.
• Check the notification scheme to see if it contains a mailing list. If it uses a mailing list and another notification item, such as Assignee, and the assignee is also within the mailing list, Jira applications can't identify the users and will send duplicate notifications.

Notifications for filter subscriptions are not sent

If you're using a custom priority icon and the priority column is visible in your filter, the same issue above may be occurring with filter subscriptions.

If your filter contains at least one issue with a malformed priority icon, no notifications will be sent for this filter. 

All legacy automation, including customer notifications, are not being triggered. This will affect all service projects in the same way

• Check the atlassian-jira.log file after a restart and search for "QClaimant must not be longer than 127 in length". Example of exception below:

  2023-04-12 12:01:16,436-0700 main ERROR anonymous     [c.a.s.core.lifecycle.DefaultLifecycleManager] LifecycleAware.onStart() failed for component with class 'com.atlassian.servicedesk.plugins.automation.internal.bootstrap.AutomationPluginLauncher' from plugin 'com.atlassian.servicedesk.plugins.automation.servicedesk-automation-plugin'
  com.atlassian.psmq.api.QException: QClaimant must not be longer than 127 in length
      at com.atlassian.psmq.api.internal.Validations.checkArgument(Validations.java:87)
      at com.atlassian.psmq.api.internal.Validations.checkMaxLength(Validations.java:79)
  ...

• This error indicates that the ServiceDesk Automation plugin is not successfully able to be started and the cause is the hostname of the node/server is longer than 127 characters. 
• The source code is evaluating if the string "com.atlassian.servicedesk.plugins.automation.execution.async.job.runner.<NODE_ID>" is longer than 127 characters which means that the node ID can only contain 55 characters, due to the prefix of "com.atlassian.servicedesk.plugins.automation.execution.async.job.runner." being 72 characters.
• If this error is found after a restart you will need to adjust the hostname configured so that it is less than 55 characters in length.

General Troubleshooting Tips

• The Notification Helper tool can help understand why a Jira notification was not sent to a specific user, from a specific Jira issue, and for a specific event:

  • This tool is located on the page ⚙ > System > Notification Helper.

  • This tool will help confirm whether a given Jira user is eligible to receive a notification based on a specific event.

  •  Note that this tool only checks if the user is eligible to receive the notification but does not guarantee that the user will receive it (since other parameters will come into play).
  • When using this tool, make sure to test the affected user along with the affected Jira ticket and the event for which this user did not receive a notification.
• Reviewing your Jira application logs will help you narrow down the problem. Often, the problem exists in the mail server, and a Google search of the error from the logs can help you identify the cause.
• The Mail Queue (under ⚙ > System > Mail Queue) can give you a general idea of the number of emails generated.
• You can get more debugging information in the Jira log files by going to the page ⚙ > System> Logging and Profiling and enabling the debugging packages listed below:
  • Click on Enable the Outgoing mail log
    • Then, underneath that, Click Enable Debugging.
  • Click on Configure logging level for another package.
    • Use com.atlassian.jira.service as the package name, and select "DEBUG" for the "Logging Level."
    • Repeat the same step with com.atlassian.jira.plugins.inform.batching.cron.BatchNotificationJob.
  • Remember to turn these off once the problem is resolved, as they can increase the overhead on server hosting, potentially cause performance degradation, and consume HDD space.
• For more detailed logging (display the message headers and protocol details), see Logging email protocols.
  • Logging email protocols is not recommended in most cases because it requires a Jira restart, and it adds logs at the Java Mail Library, which is highly verbose, will flood the log files and make them rotate very quickly.