How to reduce Jira notification noise in Jira Cloud

Updated October 21, 2026 by Pledona

When people say "Jira sends too many emails", the cause is rarely one setting. Notifications come from the space's notification settings, each person's preferences, watching, Automation rules, filter subscriptions and, in Jira Service Management, customer notifications. This guide walks through each source with the built in options first, then shows when moving team alerts to a chat space makes more sense.

Wording note: Atlassian now calls Jira projects spaces and issues work items, and this guide follows that. A Jira space is not the same thing as a Google Chat space; we always say which one we mean.

Find where the noise comes from

Before changing anything, ask two or three of the people who complain to forward one example of each email type they want gone. The subject line and the reason they got it (watcher, assignee, reporter, mention, group member) tell you which row of the table to work on.

1. Trim the notification scheme (company-managed spaces)

A notification scheme maps work item events to recipients. Jira ships a Default Notification Scheme that is associated with every new space, and one scheme can be shared by many spaces. In the default scheme, events go to the current assignee, the reporter and all watchers. You need the Jira Administrators global permission to create, edit or associate schemes; space admins can view their space's scheme but not change it.

To see which scheme a space uses, open the space, then More actions (•••) > Space settings > Notifications. To edit schemes, go to Settings > Work items > Notification schemes.

• Copy before you cut. Changes to a shared scheme hit every space that uses it. Copy the scheme, trim the copy, and associate it with one noisy space first (Actions > Use a different scheme).
• Remove group recipients from busy events. A group or space role on Work item updated or Work item commented emails everyone in it on every edit or comment. Keep groups and roles on rare events like Work item created or Work item resolved if they need them at all.
• Know what Work item updated covers. It fires for detail changes, and also when a comment is deleted. If people only care about status, rely on the transition events and drop recipients from Work item updated.
• Check Generic event. Workflow transitions can fire Generic event or a custom event instead of a named one. If a transition sends mail you did not expect, look at which event it fires.
• Drop worklog events (Work logged, Work started, Work stopped, worklog updated and deleted) unless someone truly reads them.
• Prefer space roles over named users and groups. Atlassian recommends roles because they keep the number of schemes down, and they make it easier to see who gets what.

Jira only emails people who can browse the space and who pass any work item security level, so a permission cleanup can also cut mail.

2. Edit notifications in team-managed spaces

Team-managed spaces have no shared schemes. A space admin (Administer spaces permission) edits each space on its own in More actions (•••) > Space settings > Notifications. By default, events go to the work item's watchers, assignee and reporter. For each event you can Edit the recipients (all watchers, current assignee, current user, reporter, space lead or a space role) or Delete the notification so that event sends nothing.

Jira Service Management team-managed spaces have the same idea under Space settings > Notifications > Internal notifications; customer notifications are separate (see JSM below).

3. Personal notification settings: share these with your team

Every user can filter what the admin settings send them. In Jira, select Settings > Personal Jira settings > Notification settings, then Spaces and work items:

• Turn off Send me emails for work item activity to stop all work item emails, or keep it on and choose which situations email you: watching, reporter, assignee, mentions, and your own changes.
• Use Customize space notifications to set different choices for up to 50 spaces, for example everything for your team's space and mentions only elsewhere.
• Choose in-app or email per type, so quieter updates can stay in the Jira bell.

Personal settings work as a filter on top of the admin's settings. They can remove emails, but they cannot add an email the space does not send. By default Jira does not email people about their own changes.

In General settings, Watch your work items makes you a watcher of every work item you create or comment on. On a busy space that alone can explain most of someone's email. Turning it off stops new automatic watching; it does not remove you from work items you already watch.

4. Batched email: what Jira already groups

Jira Cloud groups updates by default. For the same recipient and the same work item, Jira waits until there has been no new change for 3 minutes, then sends one summary email. Each new change restarts the 3 minute wait, up to a maximum of 10 minutes. Atlassian says this cuts email volume by about 30% on average.

• Critical updates skip the wait: mentions, newly assigned work items, alerts and SLA notifications arrive immediately.
• Grouping only works with HTML email. If someone gets one email per change, check that their Email format is HTML, not plain text.
• Grouping is per work item. Ten people editing ten different work items still produce ten emails, so batching helps with bursts, not with breadth.

Summary emails come from the name of the person who made the changes, or from "Jira" when several people did, which is useful for inbox filters.

5. Watchers and @mentions

"All watchers" is on most events in default settings, so the Watchers field is the biggest lever after the scheme itself.

• Agree as a team when to watch. Watching every work item you comment on (the default) is useful on small spaces and noisy on large ones.
• Remove yourself from work items you no longer care about from the work item's watch button.
• Use @mentions for "please look at this". A mention emails only that person, right away, and is not batched. It is better than adding someone as a watcher who then gets every later change.
• Keep the Someone mentions you checkbox on. Atlassian's docs suggest that someone who only wants mention emails clears every other box and keeps that one.

6. Audit Automation rules that send notifications

Automation rules with a Send email action, or a Send web request action that posts to chat, add to whatever the notification scheme already sends. Atlassian's own troubleshooting advice is to review overlap between default notifications and your automation rules.

• Search your rules for email and web request actions and check each one against the scheme. A rule that emails the assignee when a work item is assigned duplicates the scheme's Work item assigned email.
• Narrow triggers and put the most selective condition first, so the rule only sends what matters.
• Turn per change rules into one scheduled summary where you can. Our daily digest guide shows a rule with a Lookup work items action instead of one message per work item.

Every rule run also uses Automation steps, which are billed beyond your allowance from December 3, 2026. See how Automation steps are counted, and how to use fewer on notification rules.

7. Replace per change email with a filter subscription

For managers who want to know what moved, not every edit, a filter subscription is often better than being a watcher. Save a search as a filter, for example project = ABC AND updated >= -1d ORDER BY updated DESC, then open Details > New subscription and pick a schedule. Jira emails the results on that schedule. Only the first 200 results are sent, results are worked out per recipient (so currentUser() works), and Atlassian recommends HTML email for subscriptions. You can subscribe a group only if you are a member of it and have the Manage Group Filter Subscriptions global permission.

If the summary should be a file rather than an email body, see how to schedule Jira reports by email.

8. Jira Service Management: internal vs customer notifications

JSM sends two kinds of email, and they are configured in different places:

• Internal notifications go only to agents and admins and follow the space's notification scheme (company-managed) or Internal notifications (team-managed). Agents become watchers when they comment, post an internal note or transition a request, if Watch your work items is on, so the personal setting above matters a lot for agents.
• Customer notifications go to people who raised the request, are in the Reporter, Approver or Request participant fields, or have a request shared with their organization. In company-managed spaces, a space admin can turn each rule off in Space settings > Notifications > Customer notifications. Customers can also turn off a single request's notifications from the email or the portal.

Nobody gets notified about their own activity. If an agent is both a customer and an agent on a request (for example reporter and assignee), internal notifications take priority. For an internal help desk where every help seeker has a Jira license, Atlassian documents a way to turn off the customer notification rules and use the Jira notification scheme for everyone instead.

Move team alerts to a chat space with Threadline

Much of the noise comes from using personal email for team awareness: a group on Work item updated so "everyone knows what is going on". A shared chat space is a better home for that. Each person reads it when it suits them, and you can then remove group and role recipients from busy events in the scheme. Keep email for what is personal: assignments, mentions and approvals.

Threadline for Jira does this for Google Chat. What it can do today:

• Routes. Each route sends matching events to one Google Chat space, with its own Jira spaces (the app's Projects field), event types and filters. Up to 25 routes per site.
• Only the events you pick. Issue created, status changed, comment added, assignee changed, priority changed and resolved. Edits to other fields, such as the description, don't send a message, and comment edits only do when you tick that option.
• Filters, including JQL. Issue type, priority, status category, labels, excluded labels, assignee, and up to 1000 characters of JQL checked against each work item.
• One thread per work item, so follow ups stay together instead of filling the Chat space.
• Batching. Rapid edits to one work item within the batching window (20 seconds by default, 0 to 300) become one message. A change that is undone inside the window is not sent, and a duplicate event within 10 minutes is posted once.
• Daily digests. Real-time, real-time plus a daily digest, or digest only. The digest lists up to 30 work items in the route's time zone, and nothing is sent on a quiet day.
• Quiet hours, optionally all weekend. Held updates arrive as one "While you were away" message after quiet hours, and break-through priorities such as Highest are still sent right away.
• JSM safety. Internal (agent-only) JSM comments are left out by default, a per route setting that is on by default. Comments restricted to a group or role are not posted.
• A delivery log that shows what was sent, retried, held, or filtered and which filter did it, so you can tune routes with facts.

Limits to be honest about: it needs Google Workspace Business or Enterprise with incoming webhooks allowed by your Workspace admin, routes are set up by Jira admins (there are no per user chat preferences), and it does not replace personal email for assignments and mentions. It runs on Atlassian Forge with its own Jira event triggers, so it does not use your Automation steps. Threadline for Jira is free for up to 10 users, then $0.80 per user per month through Atlassian, and is pending Atlassian Marketplace review. See the Threadline documentation for every setting.

Prefer to build it yourself? The Jira to Google Chat guide compares the options, and the Automation webhook guide has ready to paste message formats. For service desks, see JSM alerts to Google Chat.

A 30 minute cleanup checklist

1. Collect example emails from the people who complain and note why each was sent.
2. List which notification scheme each noisy company-managed space uses. Copy the shared scheme before editing.
3. Remove groups and broad roles from Work item updated, Work item commented and worklog events.
4. In team-managed spaces, edit or delete the busiest event notifications.
5. Send your team a short note on personal settings: per space customization, the mentions only option, HTML email, and Watch your work items.
6. Find Automation rules that email or post on every change; remove duplicates and turn the rest into scheduled summaries.
7. Offer filter subscriptions to people who only need a daily or weekly view.
8. In JSM, review customer notification rules and agents' watch settings.
9. Move team wide awareness to a chat space, then remove the matching group recipients from the scheme.
10. Check again in two weeks with the same people.

Sources: Atlassian Support, Configure notification schemes, Configure spaces, Customize notifications in team-managed spaces, Manage your Jira personal settings, Batched notifications in Jira Cloud, Group notification emails together not working, Manage filters, What notifications do my customers and team receive?, Customize internal notifications in team-managed spaces, Disable service space notifications for internal users; Atlassian Community Learning, Create a notification scheme to control alerts. All checked October 21, 2026.

Frequently asked questions

Related guides

• How Jira Automation steps are counted, and how to use fewer on notification rules
• How to send Jira notifications to Google Chat
• How to send Jira Service Management alerts to Google Chat
• How to post a daily Jira digest to Google Chat
• How to schedule Jira reports by email