Why is my Jira automation rule not running?
· Andrey Guenov
When a Jira automation rule doesn't run, check the rule's audit log first — it tells you whether the rule fired at all, fired and was filtered out by a condition, or failed with an error. From there the usual causes are: the rule is disabled, its scope is wrong, the trigger doesn't match, a condition is filtering everything, the actor lacks permission, or you've hit your plan's execution limit.
A Jira automation rule that fails loudly is easy. A rule that silently does nothing is the frustrating one — no error, no email, no evidence it exists.
Start with the audit log. Every rule has one, and it answers the first question that matters: did the rule run at all?
Three outcomes, each pointing somewhere different:
- No entries — the trigger never fired. Your problem is the trigger or the rule's state.
- Entries saying no actions were performed — the rule fired, but a condition stopped it. Your problem is a condition.
- Entries with an error — the rule fired and something failed. The log names the action.
That one check eliminates two-thirds of the search space. Now work through the usual causes.
1. The rule is disabled
Obvious, and it happens constantly — especially with rules created, tested, and never turned on, or disabled during an incident and forgotten. Open the rule and confirm it's enabled.
2. The scope is wrong
Rules live either in a single project or globally across several. A rule created in one project's settings won't fire for issues in another. If you're expecting it to cover multiple projects, check that its scope actually includes them.
3. The trigger doesn't match reality
This one is subtle. "Issue transitioned" is not the same as "issue updated"; "issue created" won't fire for issues imported in bulk; a scheduled trigger fires on its schedule regardless of what you hoped would prompt it. Read your trigger literally and ask whether the event you're expecting genuinely matches it.
A useful test: if the rule works when you run it manually but never fires on its own, the problem is almost certainly the trigger, since a manual run skips it.
4. A condition is filtering everything out
If the audit log shows the rule running but performing no actions, a condition is rejecting every issue. Common culprits are a JQL condition that's stricter than intended, a status or issue-type check that doesn't match your actual workflow names, or a user condition that's never true.
Temporarily remove conditions one at a time and re-run to find which one is closing the gate. If the JQL itself is the suspect, test it in the issue navigator first — the JQL query builder is a quick way to confirm a clause returns what you think it does.
5. The rule actor lacks permission
Rules run as a user — the actor — and that user needs permission to do what the rule asks. A rule that transitions issues, adds comments, or edits fields will fail if the actor can't perform those actions in that project. The audit log usually shows a permission error when this is the cause, but it's easy to skim past.
Check who the actor is and whether they have the relevant permissions in the target project.
6. You've hit your execution limit
Automation runs count against your plan's monthly allowance, and when you exhaust it, rules simply stop. The failure is quiet — nothing errors, things just don't happen.
This catches people out most often when a rule is unintentionally running per-issue rather than once — a scheduled trigger with JQL in it will do exactly that — burning through the allowance far faster than expected. If your rules stopped working partway through a month, check your usage before debugging anything else.
A note on rules triggering rules
If your rule is supposed to fire in response to something another rule did, there's an additional setting to check: by default, changes made by automation don't trigger other rules, to prevent loops. There's an option on the rule to allow it. If you've built a chain of rules and only the first one runs, that's usually why.
The order to work in
Audit log, then rule enabled, then scope, then trigger, then conditions, then permissions, then limits. It's roughly the order of likelihood, and each step is quick.
The one habit worth building: check the audit log first, every time. It's the difference between debugging with information and guessing.
I'm Andrey. I build small, focused apps for Jira at Guenov Labs, and I write about the unglamorous parts of making Jira behave.
FAQ
- Why is my Jira automation rule not running?
- Check the rule's audit log first — it shows whether the rule triggered, and if so whether a condition stopped it or an action errored. The most common causes are a disabled rule, the wrong scope (project versus global), a trigger that doesn't match what's actually happening, a condition filtering out every issue, insufficient permissions for the rule actor, or your plan's monthly execution limit being reached.
- Where is the audit log for a Jira automation rule?
- Open the rule in the automation rule builder and look for its audit log, which lists recent executions with a status for each. A 'no actions performed' entry means the rule fired but a condition stopped it; an error entry points at the failing action; no entries at all means the trigger never fired.
- Why does my rule work when I run it manually but not automatically?
- That pattern usually points to the trigger rather than the actions, since a manual run bypasses it. Check that the trigger matches the real event, that the rule is enabled and scoped to the right project, and — for rules meant to be triggered by other rules — that the option allowing rule-triggered execution is enabled.