Why does my Jira automation send a separate email for each issue?

Because the JQL is in the scheduled trigger. When a scheduled trigger matches issues directly, the rule executes once per matching issue, and any email action inside it fires each time. Leaving the trigger's JQL empty and putting the query in a separate Lookup Issues action makes the rule run once, with all issues available to a single email.

How do I send one summary email from Jira automation?

Use a Scheduled trigger with no JQL, add a Lookup Issues action containing your query, then a Send email action whose content loops over the results with a smart-value block. The loop repeats per issue inside one email rather than sending one email per issue.

Does each email count against my automation limits?

Rule executions count against your plan's monthly automation allowance, so a rule firing once per issue burns through it far faster than a single summary rule. Fixing the trigger reduces both the inbox noise and the consumption.

Why does my Jira automation send a separate email for every issue?

You built a scheduled rule to email a weekly summary. It works — except instead of one email listing seventeen issues, seventeen emails arrive, each listing one.

The cause: your JQL is in the scheduled trigger.

When a scheduled trigger contains a JQL query, it matches issues directly, and the rule then executes once per matching issue. Every action inside the rule — including the email — runs each time. Seventeen matches, seventeen executions, seventeen emails.

The fix

Move the query out of the trigger and into a Lookup Issues action.

Open your rule and select the Scheduled trigger.
Clear the JQL field. Leave it empty. Keep the schedule itself (weekly, Monday 9am, whatever you set).
Add a Lookup Issues action as the next step, and put your JQL there.
In your Send email action, loop over the results rather than referencing a single issue.

The loop looks like this:

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

That block repeats once per issue inside one email, producing a clean list instead of a flood. If you're building this rule from scratch rather than repairing one, the full weekly summary email walkthrough sets it up correctly from step one, and the smart values reference covers what else you can put inside that loop.

Why the trigger behaves this way

It isn't a bug. A scheduled trigger with JQL is designed for "do something to each matching issue" — transition every stale ticket, add a label to everything unresolved. Per-issue execution is exactly right for that.

It's the wrong shape for reporting, where you want the rule to run once and treat the issues as a collection. Lookup Issues exists precisely for that: it gathers matches into a set the rest of the rule can work with as a whole.

The two patterns look nearly identical in the rule builder, which is why almost everyone hits this once.

Two things to check while you're in there

The Lookup Issues result cap. The action returns a limited number of issues per run, so a broad query can silently miss items. Narrowing the query with a time window (something like updated >= -7d) usually solves it and produces a more readable email anyway.

Your execution count. Every rule run consumes one execution from your plan's monthly automation allowance. A rule firing once per issue eats that allowance dramatically faster than a single summary rule — so this fix isn't just cosmetic, it reclaims budget you were burning on duplicate emails. The automation usage calculator will tell you roughly what your rules are costing you a month.

Test before you trust it

Use the rule builder's manual run option to fire it once immediately and check what actually arrives. It's much easier to catch a formatting problem now than to discover it when the real Monday send goes to your stakeholders.

The one sentence worth remembering: JQL belongs in Lookup Issues, 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 Guenov Labs. This uses only native Jira automation — no app required.