keelapps/Guides

How to customize Jira Cloud notification emails

Jira Cloud · Updated 7 October 2026

Jira Cloud decides who gets its notification emails, but not what they say: the subject and body are fixed for every project. To send your own wording you add a second message on top. This guide covers what Jira lets you change, three ways to send custom emails, what each one costs, and how to keep people from getting the same news twice.

We make Mail Templates, one of the options below, so we are not neutral. The native route comes first and needs no app.

What Jira lets you change

• Who is emailed, per event. In company-managed projects the notification scheme maps each event, such as issue created or issue resolved, to recipients: reporter, assignee, watchers, a role, a group. In team-managed projects the same choice is under Project settings → Notifications.
• What each person receives. Each user can turn categories of email on or off in their own notification settings.
• Not the words. There is no template editor for Jira’s own emails in Cloud. The request, JRACLOUD-7266, has been open since 2005.

One exception: in a Jira Service Management project, the notifications sent to customers have editable templates under the project’s customer notification settings. This guide is about the emails your own team and internal stakeholders get from Jira.

Why teams want their own wording

• People outside the team. A customer-success group, a client sponsor or finance needs “Release 4.2 is done” in plain words, not a Jira change digest with field names.
• A subject line people can filter. Something like [REL] REL-42 — Payments release sorts into a mail rule; Jira’s default subjects vary by event.
• Fewer, better emails. One message when an issue reaches Done, instead of every comment and field edit along the way.
• Instructions in the mail. “Approve in the issue by Friday” belongs in the body, which Jira’s template cannot carry.

Option 1: Automation’s Send email

Jira Automation can send an email with your own subject and body. For a status change it looks like this:

1. Project settings → Automation → Create rule.
2. Trigger: Issue transitioned, optionally limited to a target status such as Done.
3. Action: Send email. Pick recipients (reporter, watchers, a group, or addresses) and write the subject and body with smart values, for example {{issue.key}} — {{issue.summary}} is now {{issue.status.name}}.
4. Turn the rule on and move a test issue to check the result.

Automation is free to start and flexible. The costs show up later:

• Usage. Every run counts toward your plan’s automation allowance. A rule that fires on every status change in a busy project is one of the fastest ways to use it up.
• One rule per event, per project. Three events across ten projects is thirty rules to keep in step, unless you write global rules with conditions.
• No real preview. You see the mail by triggering the rule on a real issue.

Option 2: a template app

A Marketplace app can attach a template to each event in a project and send it when the event fires. When comparing apps, check:

• How mail is delivered. Through Jira’s own notification service, or through the vendor’s mail server. The second means your issue fields leave Atlassian on the way to every recipient.
• A preview that is the real email, not an approximation, so what a project admin approves is what goes out.
• A send log that records events that sent nothing, and why. “Why did no email arrive?” is the question you will be asked most.
• Restricted comments. A comment visible only to a role or group, or a service project’s internal note, must never be mailed to a wider list.
• Limits on volume. A bulk edit of 500 issues is 500 events. An hourly cap keeps one mistake from becoming 500 emails.

Option 3: an external mail service

A webhook or Automation’s Send web request can hand issue data to an outside service that sends the mail. That is the only route to a custom sender address, attachments or unsubscribe links. It also sends your issue data to a third party, adds a system to secure and maintain, and needs its own review for compliance. Most teams that only want better wording do not need it.

The options side by side

For one or two rules, Automation is the simple answer. Once several projects want their own wording, or your automation allowance is tight, a template per event is easier to keep in step.

Avoiding duplicate mail

None of these options can stop Jira’s own email. Forge apps have no hook to suppress it, and Automation does not either. So a watcher who already gets Jira’s “status changed” mail will also get yours. To avoid that:

1. Decide who each message is for. Often the custom email goes to people Jira does not notify at all, and there is nothing to fix.
2. Find the project’s notification scheme and check which other projects use it. Schemes are frequently shared, and a change applies to all of them.
3. Turn the event off for the overlapping recipients, in a copy of the scheme if it is shared, and assign the copy to this project.
4. Send a test by moving an issue, and confirm each person receives one message.

Questions

Can I edit Jira Cloud’s email templates?

No. Jira Cloud’s own notification emails have fixed wording; you can change who receives them, not what they say. The request to change that, JRACLOUD-7266, has been open since 2005. Jira Service Management’s customer notifications are the exception: those templates are editable.

How do I send a custom email when a Jira issue changes status?

Create an Automation rule with the Issue transitioned trigger and a Send email action, and write the subject and body with smart values such as {{issue.key}}. Or use an app that gives each project a template per event.

Do Automation emails count against my automation limit?

Yes. Every run of a rule that sends email counts toward your plan’s automation usage, so a rule that fires on every status change in a busy project uses it up quickly.

How do I stop people getting two emails for the same change?

Neither Automation nor an app can suppress Jira’s own notification. Turn the matching event off in the project’s notification scheme for the people your custom email now covers, after checking which other projects share that scheme.

Can a custom Jira email include attachments or come from my own address?

Not when it is delivered by Jira. Jira sends from its own address, and attachments or a custom sender need an external mail service, which means your issue data leaves Atlassian.

Where Mail Templates fits

Mail Templates for Jira is option 2. Each project gets one template for each of three events: issue created, status changed and comment added. Subject and body take 19 issue variables, from {{issue.key}} to {{transition.to}}, and a small markdown subset. Recipients are any mix of reporter, assignee, watchers, voters, named people and groups. The preview under the editor is rendered by the same code that sends the mail.

Mail goes out through Jira’s own notification service, so it uses none of your automation allowance and nothing leaves Atlassian. Jira still drops anyone who cannot see the issue, restricted comments and internal notes are never mailed, and hourly limits per project and per site cap a bulk edit. A send log names the result of every event, including the ones that sent nothing.

What it does not do, by design: it cannot suppress Jira’s own email, and it will never add attachments, a custom sender address, unsubscribe management or a rich-text editor, because each would need egress or permissions this app exists to avoid. It is free for sites of up to 10 users.

Try Mail Templates free