Troubleshoot notifications in Jira

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

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.

Symptoms

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


For more detailed troubleshooting about slow/stuck notifications, you can refer to the KB article Troubleshooting slow/stuck notification issues in Jira/Service Management Server/Data Center, which lists all the known root causes for the situation where anyone receives no notification emails from the Jira application.


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.
  • In case these users did not receive the notification from a specific workflow transition, it is important to note that their post-function triggers notifications in a transition. In such a case, you will need to 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.


For more detailed troubleshooting about this scenario, refer to the KB article Troubleshooting why a Jira user did not receive a notification from a ticket while this user was expecting to receive it, which lists all the most common root causes.

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)


For more detailed troubleshooting about this scenario, you can look at the KB article A Jira user received a notification from a ticket while this user was not expecting to receive it, which lists all the most common root causes.

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 are different, the notification is likely coming 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 content of the notification 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 Outbound mail fails to send in Jira server 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. Remove the "Issue Created" event trigger from the third-party app if that's the case.
  • 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. 

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

    • (warning) 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 how many emails are 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
    • (warning) 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.
    • (warning) 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.


Last modified on Apr 1, 2024

Was this helpful?

Yes
No
Provide feedback about this article

In this section

Powered by Confluence and Scroll Viewport.