How to set up a Jira Automation rule to email a weekly summary

If you're manually copying Jira updates into an email every week, you can stop. Jira can send that email itself, on a schedule, to anyone — including people who don't have a Jira account. It's built in, it's free, and it takes about ten minutes to set up.

There's exactly one non-obvious trap that catches almost everyone the first time, and it's the reason your rule sends seventeen separate emails instead of one summary. I'll show you how to avoid it.

Here's the whole thing, step by step.

What we're building

A rule that, every Monday morning, finds the relevant issues in your project and sends one email containing a tidy list of them — what's done, what's in progress, whatever you choose. To a colleague, a manager, or an external stakeholder with no Jira seat — this is one of the native routes for getting information to someone without a license; see gour rundown of what's actually possible on that front if this is only part of the puzzle for you.

Step 1: Open the automation builder

Go to Project settings → Automation for a rule that covers one project, or Settings → System → Automation for a rule that spans several. Click Create rule.

(If you don't see Automation in project settings, you may be on a plan or permission level that only exposes global automation — the global path works fine either way.)

Step 2: Add a Scheduled trigger — and leave its JQL empty

Choose Scheduled as your trigger. Set the cadence: weekly, on the day and time you want (say, Monday at 9am). You can use the simple interval picker or a cron expression for finer control.

Here is the trap. Do not put a JQL query in the scheduled trigger.

The scheduled trigger has an optional JQL field, and it's tempting to put your query there — "find all issues where status changed this week." If you do, the rule runs once per matching issue, and you'll get one email for every single issue. That's the seventeen-emails problem, and it's the single most common mistake with this rule.

Leave the trigger's JQL blank. We'll do the query properly in the next step.

Step 3: Add a "Lookup Issues" action with your JQL

Add a new action: Lookup Issues. This is where your query goes.

Put your JQL here. Some useful examples:

• Everything updated in the last week: project = ABC AND updated >= -7d ORDER BY updated DESC
• Recently completed work: project = ABC AND status changed to Done AFTER -7d
• What's currently in progress: project = ABC AND status = "In Progress" ORDER BY priority DESC

Lookup Issues gathers all the matching issues into a single collection the rest of the rule can use. Note the limit: it returns up to 100 issues per run. If your query could match more, tighten it (a time window like updated >= -7d usually does the job) or split into multiple rules.

Step 4: Add a "Send email" action

Add the Send email action. Fill in:

• To: any email address — a teammate, a manager, or an external stakeholder with no Jira account. (This is the part people don't realise: automation emails go to anyone, licensed or not.)
• Subject: something like Weekly project update — {{now.j:EEEE, d MMM}}
• Content: here's where you turn the looked-up issues into a readable list.

To list the issues you found, loop over them with smart values:

Here's this week's update on the project:

{{#lookupIssues}}
- {{summary}} — {{status.name}}
{{/}}

That {{#lookupIssues}} ... {{/}} block repeats once per issue, producing a clean bulleted list in a single email. You can add more per issue — assignee ({{assignee.displayName}}), a link ({{url}}), the due date ({{duedate}}) — but resist the urge to include everything. The person reading this doesn't want a data dump (more on that below).

Step 5: Name it, turn it on, and test

Name the rule something obvious ("Weekly stakeholder summary"), then use Jira's built-in run rule / test option to fire it once immediately and check the email looks right. Adjust the content, then publish.

That's it. Every Monday, the email sends itself.

Two things worth knowing before you rely on it

It counts against your automation limit. Every rule run consumes one execution from your plan's monthly allowance. A weekly rule is trivially cheap — about four runs a month — but the allowance is real, and it's small on the Free plan. If you build a lot of automation, keep an eye on it.

A list of issues is not the same as a summary — and this is the honest limitation. This rule is excellent at answering "what changed this week?" for someone who understands Jira. It's a report. What it can't do is interpret: it won't tell your reader whether the project is on track, what the changes mean, or what to worry about. It lists PROJ-241 — In Progress; it doesn't say "the login work is on schedule, the payment integration is a week behind." If your recipient is a fellow team member, the list is perfect. If your recipient is a non-technical client who needs the meaning rather than the mechanics, you'll still want to add a sentence or two of interpretation yourself before it goes out — automation can send the facts, but it can't yet do the judgement. (If that's the recipient you're dealing with, gour guide to sharing Jira status with a client who doesn't have a license covers the full set of options for getting them an actual interpretation, not just a ticket list.)

For a lot of use cases, though, the facts on a reliable schedule are exactly what's missing, and this rule delivers them for free. Set it up once, and reclaim your Monday mornings.

Quick reference

1. Project settings → Automation → Create rule
2. Scheduled trigger — set the cadence, leave JQL empty
3. Lookup Issues action — put your JQL here (max 100 issues)
4. Send email action — recipient (any address), subject, and a {{#lookupIssues}}...{{/}} loop for the issue list
5. Test, then publish

The one thing to remember: JQL goes in the Lookup Issues action, never in the scheduled trigger. Get that right and you get one clean summary instead of an inbox full of single-issue emails.

---

I'm Andrey. I build small, focused apps for Jira at gGuenov Labs. This tutorial uses only native Jira features — no app required.