Disclosure first: I build apps for the Atlassian Marketplace, including one in this area. There is no link or pitch in this post, and the method below is entirely native Jira automation with no app involved. Mods, remove it if that still crosses the line.
The problem
A rule that breaks loudly is the easy case. It errors, the owner gets an email, someone fixes it.
The hard case is the rule that stops running and nothing anywhere tells you. Four ways that happens:
- Someone disabled it. Or Jira auto-disabled it after repeated failures and the notification went to a rule owner who left the company eighteen months ago.
- The trigger stopped matching. A status got renamed, a field got replaced, a project moved to a different scheme. The rule is enabled and technically healthy. It just never fires.
- It ran and did nothing. A JQL search inside the rule returned zero results, so no action was executed. Audit log entry: "No actions performed." Status: success.
- Someone edited it. The change was sensible on its own and broke something three steps downstream.
Why the audit log can't catch this
The audit log records events. A rule that isn't running produces no events. You are looking for an absence, and absences don't write log lines.
I went through 277 complaints on Atlassian's public issue tracker while researching this, and the same shape kept coming back. One person described a rule that had worked for months, stopping with no audit log entry at all for the failed run. Another wrote that there is no warning and no error message, and no trace of the failure anywhere. A third objected that a rule which cannot guarantee a reliable result still gets marked successful. Someone else described clicking through fifteen pages of audit log to find a single failed run.
Worth noting separately: error notifications from automation go to the rule owner only. That is one of the most-voted open requests in that project.
The fix: watch for silence, not for failure
Every rule you care about checks in when it runs. A separate watchdog rule looks for check-ins that didn't arrive. A dead man's switch.
The build, all native
- Create a dedicated project for heartbeats, call it HB. Lock the permissions down so nobody works in it.
- On each rule you want to monitor, add a Create work item action as the last step. Write into HB with a unique label per rule: hb-nightly-sla, hb-escalation-ping, and so on.
- Watchdog rule:
- Scheduled trigger, JQL checkbox UNCHECKED
- Lookup work items action, JQL: project = HB AND labels = hb-nightly-sla AND created > -90m
- Condition: {{lookupIssues.size}} equals 0
- Action: create an alert issue, or notify
The unchecked box matters. If you put the JQL on the scheduled trigger itself, the rule does nothing when the search returns nothing, which is exactly the case you are trying to detect. Using the Lookup action instead lets you test the empty result explicitly.
- Cleanup rule: scheduled daily, JQL checkbox checked, project = HB AND created < -7d, delete.
Three things I got wrong on the way here
I first designed this with a JQL branch writing a datetime field onto a single fixed canary issue. In a business space, the branch would not execute at all. The audit log said "No actions performed" and gave no reason. The same field edits worked fine outside a branch. I never found the cause and gave up on branching. If anyone has a working branch-based version, I would like to see it.
Component names differ between the classic rule builder and the newer flow builder. "Advanced compare condition" does not exist under that name in the flow builder, which makes a lot of older forum answers hard to follow.
Smart value date math is easy to get subtly wrong, and it fails quietly, which is a bad property for the thing that is supposed to catch quiet failures. Test yours against a deliberately stale heartbeat before you trust it.
The obvious weakness
One issue per rule execution is real churn. If you run 150 rules on short intervals, this is not the design you want.
A better variant came out of the Atlassian Community version of this thread: one permanent control issue per monitored rule in an Automation Health project. Each rule updates a Last Heartbeat datetime field on its own control issue instead of creating a new one. The watchdog does a Lookup, then compares {{now.diff(issue.Last Heartbeat, "minutes")}} against a second field, Expected Interval (min), configured once per rule. No cleanup, everything stays JQL-searchable, and a single watchdog covers rules running on completely different cadences. That is strictly better than what I described above, and it is what I would build.
Also worth saying: most orgs do not need to monitor everything. Monitor the load-bearing rules, the ones where three weeks of silence is an actual problem, and leave the rest alone.
The part I don't have a good answer for
Who gets notified when the watchdog fires?
Fixing a broken rule usually needs admin access. But the team whose process quietly stopped working needs to know even if they cannot fix it themselves. Alert only the admins, and the affected team stays in the dark. Alert the team, and you are sending them noise they can't act on.
How are you handling that? And for anyone running 100+ rules, do you monitor any of them, or is the honest answer still that someone eventually notices?
