How do you find out when a Jira automation rule has silently stopped running?

[Automation Monitor App]

Quick disclosure first: I'm a Marketplace Partner, and I build an app in this space. Most of this post is about the problem and a method you can build with native Jira automation and no app at all — that's the long section in the middle. There's one short mention of my app near the end, clearly marked. If the DIY method is all you take away, that's a good outcome.

---

Something I keep running into, and I'd like to know how other admins handle it.

An automation rule stops running. Nothing breaks loudly. No error appears. Nobody is notified. The work the rule was doing simply stops happening, and you find out days or weeks later when someone asks why the escalations stopped, or the reports never arrived, or a customer never got a response.

This is different from a rule that errors. A rule that errors leaves a trace. The failures that actually hurt are the ones that leave nothing behind at all.

If you spend time in the public Jira issue tracker you'll find this described over and over. A few examples, in the words of the people who filed them:

• AUTO-2212 — "A rule that had been working for months suddenly stopped. Troubleshooting it, the audit log showed no entry at all for the failed run."
• AUTO-2080 — "It occurs randomly. There is no warning or error message, there is no trace of this error anywhere."
• AUTO-1218 — "It is not acceptable for an automation rule, which cannot guarantee a reliable result, to be marked as 'Successful.'"
• AUTO-65 — "We had a rule fail after someone updated it and forgot what they changed. It resulted in our system being throttled for hours."

That last one is the shape of the real cost. Not the failure itself — the time between the failure and the moment someone noticed.

Four ways a rule goes quiet

Worth separating these, because they need different responses:

1. The rule was disabled. Sometimes deliberately, sometimes as a side effect — imports, restores, and bulk configuration changes can leave rules switched off. Nobody gets told.

2. The trigger stopped matching. A field was renamed, a status was retired, a project moved to a different scheme. The rule is enabled and healthy; its trigger just never fires. A trigger that doesn't fire writes nothing to the audit log, which is why this one is so hard to spot.

3. The rule ran but did nothing useful. A condition silently excluded everything, a branch matched zero work items, or an action failed inside a branch while the overall run still reported success. Worth knowing: a JQL search that matches nothing is recorded as "No actions performed" — a success status, not an error.

4. Someone edited it. The rule still runs, but not the way you think. Audit entries for edits are often just "automation rule was edited" — as AUTO-65 puts it, "This is absolutely useless to me."

Why the audit log doesn't rescue you

The automation audit log is the obvious place to look, and it's genuinely useful for debugging a rule you already suspect. It's much weaker as a detection tool, for three reasons.

It can't record an absence. If a rule never triggered, there's no entry to find. You cannot search your way to a run that never happened.

It doesn't scale to browsing. From AUTO-28: "I just had to click through 15 pages to find the one rule run that threw an error." From AUTO-36: "Hours of time wasted over the last 3-4 years having to manually click and scroll through the entire historical set of audit logs to find one failure." Finding a problem in the audit log requires already knowing there is one.

Notification is narrow. From AUTO-109: "Error notifications from automations are only sent to the rule owner — a significant operational risk. Automations are often business-critical, and failures can go unnoticed." If the rule owner has left the company, changed teams, or filtered those emails, nobody is watching.

There's a long-standing request for programmatic access to the audit log (AUTO-51, one of the most-voted requests in that project) which would help a lot. It isn't fully there yet.

The pattern that works: a dead man's switch

Borrowed from cron monitoring, and it inverts the problem.

Instead of watching for a failure signal — which may never arrive — you have the rule prove it is alive on a schedule. If the proof stops arriving, that absence is the alert.

This works precisely because it doesn't depend on the rule reporting its own failure. A rule that is disabled, whose trigger stopped matching, or that silently did nothing, all produce the same observable outcome: the check-in didn't happen.

Building it natively, with no app

Three pieces: a heartbeat action added to the rule you want to watch, a watchdog rule, and a cleanup rule. No custom fields, no branching, no screen configuration.

Tested on the newer flow-based automation builder in a company-managed project. Menu labels differ slightly on the classic builder.

Step 1 — Create a heartbeat project

Create one project to hold heartbeat records — call it HB. Nothing else lives here, so it stays out of your real boards and searches.

Step 2 — Add a heartbeat action to the rule you're monitoring

This is not a new rule. Open the existing rule you want to watch, and as its last action add Create work item:

• Project: HB
• Work type: Task
• Summary: Heartbeat: Nightly SLA escalation (name it after the rule)
• Labels: hb-nightly-sla — one unique label per monitored rule. This is what the watchdog keys off, so it must be distinct.

That's the entire change to your monitored rule. Nothing else about it moves.

Step 3 — Build the watchdog

This is the piece that needs care, because you're detecting an absence, and Jira automation doesn't alert on an empty JQL result by default. A scheduled rule with "Run a JQL search" checked simply does nothing when the search returns zero rows — which is exactly the case you want to catch.

The fix is to run the search as an action and then test the result count.

1. Trigger: Scheduled. Set your interval — hourly is a reasonable default. Leave "Run a JQL search and execute actions for each work item" UNCHECKED. With it checked, everything downstream runs once per matching item, which is the opposite of what you want here.

2. Action: Lookup work items. JQL:

   project = HB AND labels = hb-nightly-sla AND created > -90m

   Set -90m to roughly 1.5× the interval of the rule you're monitoring.

3. Condition: {{smart values}} condition.

   • First value: {{lookupIssues.size}}
   • Condition: equals
   • Second value: 0

4. Action: Create work item (in your triage or ops project) or Send email. This only runs when the lookup found nothing — i.e. the monitored rule hasn't checked in.

Step 4 — Clean up old heartbeats

Heartbeat items accumulate — one per run of every monitored rule. A daily scheduled rule keeps it bounded:

• Trigger: Scheduled, daily. "Run a JQL search" CHECKED this time — you do want per-item execution here.
• JQL: project = HB AND created < -7d
• Action: Delete work item

Test it properly

Getting a "rule is alive" pass proves almost nothing. Disable the monitored rule, wait past the window, and confirm the alert actually fires. The absence path is the whole point, and it's the one that's easy to leave broken without noticing.

Where this approach gets awkward, in fairness:

• One watchdog rule per monitored rule, since each needs its own label and its own staleness window
• Heartbeat work items are created on every run, so a rule firing every 5 minutes produces a lot of churn — the cleanup rule handles volume, but it's still real activity in your instance
• Scheduled rules and created items both consume automation executions, which matters on some plans
• The watchdog rule is itself unmonitored — the classic "who watches the watchmen" problem
• Team-managed and business projects have narrower automation capabilities; I originally built this with a JQL branch writing to a custom field and could not get the branch to execute at all in a business space. The version above avoids branching entirely, which is partly why I settled on it.

For three or four critical rules this is completely reasonable, and I'd recommend it over installing anything. It's the per-rule setup that grows.

A few other habits worth adopting

Name rules so ownership is obvious. [Support] Escalate P1 after 2h beats Copy of Copy of rule 3. When something breaks at 4pm on a Friday, the name is the first thing anyone reads.

Don't let one person own every rule. Given that error notifications go to the rule owner, an owner who leaves means those alerts go nowhere.

Turn off "Delay execution until we've received a response" on web request actions unless you actually need the response. Useful while testing, unnecessary overhead afterwards.

Review your rule list quarterly. Sort by last-run date. Anything that hasn't fired in months is either broken or no longer needed, and both are worth knowing.

The packaged version

(Vendor mention — this is the app I disclosed at the top. Skip this section if you're not interested.)

I built Automation Monitor for Jira because maintaining a watchdog rule and a label per monitored rule doesn't scale past a handful. It's the same dead man's switch pattern with the bookkeeping removed: you create a monitor, paste its URL into your rule as a Send web request action, and if that rule stops checking in you get a Jira issue in a project you choose — with how long it's been silent and a triage checklist.

Free for up to 10 monitors per site, and it runs entirely on Atlassian infrastructure with no external requests, so nothing leaves your site.

The DIY method above genuinely works. Use whichever fits.

What I'm actually curious about

Automation quietly doing nothing is worse than automation visibly failing, because visible failures get fixed the same day. The fix isn't better dashboards or more diligent audit-log reading — it's making silence itself detectable.

So: has this happened to you, how did you find out, and how long did it take? That gap is usually the expensive part, and I'd like to know whether other admins have found something better.

[Chris Bezile]

Very valid use cases and real world scenarios described here!  I like it.
Yes, it's happened to me and sorting through the logs is, as mentioned, a tedious chore.  Fortunately I'm aware of the automations I expect and I was able to drill in a double check configurations, etc to find the culprit.  However, at scale you're right.  Great solution!

[Automation Monitor App]

Thanks Chris — and that's the exact split I was hoping someone would name. Knowing your own automations works, right up until it doesn't: you're on holiday, or you've moved teams, or the instance has grown past what one person can hold in their head. The knowledge itself becomes the single point of failure. Out of interest, roughly how many rules are you running? I'm curious where other admins find the line between "I'd notice" and "I need something watching."

[Mykenna Cepek]

Makes me wonder who should be notified when the watcher squawks. It should probably cast a wider net. But likely not everyone on the team is a Space Admin (which is required for access to Automation flows) and thus couldn't triage or fix the problem.

[Automation Monitor App]

That's the sharpest version of this problem, and I don't think I addressed it properly in the post.

There are really two audiences with different needs. The people who can fix it are Space Admins, and that's a narrow group. But the people affected by the breakage often need to know even though they can't fix anything — if the escalation flow stopped firing, the support team needs to know to escalate manually until someone repairs it. Telling only the admins means the affected team keeps operating as if the automation is still working, which is how you end up with weeks of quiet damage like your "TO DO" example.

So probably: broad awareness, narrow accountability. One reason I like alerts landing as work items rather than emails is that it splits cleanly — anyone affected can watch the project, and the item gets assigned to whoever actually has the access to fix it. Non-admins can add context in comments even if they can't touch the flow.

Worth noting this is essentially what AUTO-109 is asking for, and it's one of the most-voted requests in that project. Your instinct that it should cast a wider net is well supported.

[Chris Bezile]

We're running about 150 automations, but I'm not the "watcher" for all of them.  Although teams come to me when they notice something not working (hence me being an admin who can't remember everything).  When issues arise on our sites the teams know to open a ticket and an admin will get it resolved (I'm the primary but there are a couple other folks with permissions and knowledge to take care of some low hanging fruit if I'm unavailale).
I like your solutions but do worry about scale, too many heartbeat issues, etc.  It looks like others on this thread touch that and have ideas too.

[Automation Monitor App]

@Chris Bezile 

150 is a helpful data point, thanks. And the pattern you describe is the one I'd expect at that scale: nobody watches all of them, teams notice breakage and open a ticket, and an admin fixes it. That works. The cost is buried in the detection delay, and it only shows up when a rule breaks that nobody is downstream of quickly.

Mykenna's example earlier in the thread is the sharp version of it: a status rename that broke multiple flows, one caught immediately, another not reported for weeks.

Your scale worry about the heartbeat issues is fair, and I think it's the weakest part of what I originally wrote. At 150 rules, one heartbeat issue per execution is genuinely unworkable; a handful of frequent rules alone would generate thousands of issues a week, and that's before the cleanup rule has to churn through deleting them.

Esther's control-issue version fixes exactly that: one permanent issue per rule instead of one per execution, so 150 rules means 150 issues total rather than 150 issues an hour. Nothing to purge, and it stays JQL-searchable so a single watchdog can cover everything. That's the version I'd point you at rather than mine.

The other thing worth taking from your setup: you don't need heartbeats on all 150. Most automations aren't load-bearing. It's probably ten or fifteen where silent failure actually costs something: the escalations, the syncs, anything customer-facing, and monitoring only those keeps the overhead trivial regardless of which approach you pick.

[Mykenna Cepek]

First off - great topic! Thanks for the article.

Has this happened to me? Of course! One example: a Jira Admin changed the name of the "To Do" Status to be "TO DO". No idea why, but you can image all the quiet breakage. I found one flow right away, but another flow took weeks before the affected team reported the problem. Eventually I convinced the Jira Admins to put the original Status name back.

If I were implementing a heartbeat solution for automation flows, I wouldn't create work items in a Jira space. At our org we have disabled the deletion of work items in Jira, so the work item cleanup in Step 4 is not even an option. Not needing a new Jira Space eliminates your Step 1.

For the heartbeat action in Step 2, I would set an (Entity) Property on the Space hosting the rule. The Property Name could match the Flow Name. The action would simply update the Property with any value (e.g. "1").

The watcher action in Step 3 simply reads the property value and sends up the flare if there is no value. If there is a value, the watcher clears it, handling Step 4 as well.

Global flows, of course, will need a separate designated Space for these watcher Properties. For us this would be the Space that the Jira Admins use to track their work (as they own the global flows).

One watcher per Space would handle all the flows in that Space. This also keeps the ownership clear and contained. Space Admins writing flows will need education and documentation about this heartbeat pattern.

I haven't actually implemented this (yet!) but this would be my approach. Open to feedback on it!

[Automation Monitor App]

That status rename is a perfect example — "To Do" to "TO DO" is invisible to a human reader and fatal to every flow keying off it. And weeks before anyone reported it is exactly the gap I'm on about.

Your entity property approach is better than mine in several ways and I'd like to think it through properly. Three things I'd want to test before recommending it:

1. Does automation set and read project entity properties natively? I've used the issue-level equivalent, but I'm not certain the Space/project level is exposed in the action and the smart value. Have you confirmed that, or is it the part you'd need to prove first?
2. Can a flow clear a property, or only overwrite it? Your self-resetting design depends on "no value" being distinguishable from "empty value" in the watcher's condition.
3. The one-watcher-per-Space tradeoff. Since the watcher clears the flag, its interval has to be at least as long as your slowest monitored flow — otherwise a flow that runs hourly gets flagged by a 15-minute watcher. So a Space containing both an hourly flow and a 5-minute flow would need the watcher set to hourly, and the fast flow's failures go undetected for up to an hour. Per-flow windows cost more setup but buy tighter detection.

Worth it either way for the reduced overhead, I think. One thing my version has going for it is visibility — you can look at the heartbeat items and see state. Entity properties are invisible in the UI, which is fine until you're debugging the monitor itself.

If you do implement it, I'd genuinely like to hear how it goes.

[kh-federico]

Hi @Automation Monitor App 

If you're part of a Marketplace App team, we would like to ask you to follow the steps outlined here to get an 'Atlassian Partner' lozenge for your profile! Cheers!

[Automation Monitor App]

Thanks for the pointer; I'll get that sorted. I've been disclosing my Marketplace Partner status in the post and comments, but good to have it on the profile properly.

Appreciate the heads up.

[Esther Ortega]

Nice thread @Automation Monitor App , and I really like Mykenna's approach of using entity properties instead of creating an issue for every heartbeat: it sidesteps exactly the "you have to purge old issues" problem you mention in the original post.

It occurs to me there's a third option that mixes both ideas and I think it addresses a few of the open questions.

Instead of creating an issue per execution (which then need cleaning up) or relying on project entity properties (which aren't JQL-searchable, so the watchdog would have to read them via the API), I'd use a single control issue per rule, living in a dedicated project like "Automation Health". Each monitored rule, at the end of its flow, updates a date/time field like "Last Heartbeat" on that fixed issue, using the native Edit issue action (or, if you'd rather not spend a custom field, the native Set entity property action at the issue level).

The advantage of working at the issue level rather than the project level is that it's actually indexed in JQL, so the watchdog itself can do a Lookup issues with JQL against the control project, and in a for-each loop compare {{now.diff(issue.Last Heartbeat, "minutes")}} against a second field, "Expected Interval (min)", which you configure once per rule on that same issue. That way each rule can have its own interval without the watchdog having to match the fastest rule's cadence, which was one of the drawbacks you mentioned about the per-Space approach.

If you're on Premium or Enterprise, Automation analytics lets you see executions per rule per day, which is really handy for calibrating that "Expected Interval" with real data.

Nice side effect: since everything lives as issues in a normal project, you can build a dashboard/filter showing the health of all your rules at a glance, instead of having to go digging through invisible properties.

One more thing on top of all this: the heartbeat covers the "the rule stopped firing" case, but it doesn't replace the native email alert Jira sends when a rule gets auto-disabled after repeated errors. I find that email useful too, so I'd keep both running in parallel.

Thanks for raising this, it's a problem that's easy to overlook until it bites you — happy to compare notes if anyone tries this approach.

[Automation Monitor App]

This is better than either of the previous versions, and the JQL point is the reason why.

Entity properties solve the cleanup problem but create a searchability problem — the watchdog has to reach for the API to read them, which puts it outside what most admins will build natively. Your control-issue approach keeps the cleanup benefit (one issue per rule, forever, no purging) while staying in JQL where automation can actually work with it.

The "Expected Interval (min)" field is the part I hadn't considered and it fixes a real weakness. Both my version and Mykenna's force the watchdog's cadence to match the slowest monitored rule, so a 5-minute rule sharing a watchdog with an hourly one goes undetected for up to an hour. Storing the interval on the control issue and comparing per-rule means one watchdog handles rules of any cadence correctly. That's a straight improvement.

Two things I'd want to test before recommending it, both from problems I actually hit building the original version:

First, whether the Edit issue action reliably targets a fixed issue from inside another rule. I tried exactly that with a JQL branch and could not get the branch to execute at all in a business space — that's what pushed me to the Create work item approach. Might be a company-managed versus team-managed difference, or the new flow builder versus the classic one, but worth confirming before others follow the steps.

Second, whether {{now.diff(issue.Last Heartbeat, "minutes")}} resolves cleanly inside a lookup loop. Date math in smart values is one of the areas where things silently return nothing rather than erroring.

Good call on keeping the native auto-disable email running in parallel — those catch a different failure mode, and there's no reason to replace something that already works.

Between the three versions in this thread there's a decent article's worth of material. If you or Mykenna do implement it, I'd like to hear how it goes.

[Isaac Trumbo]

Great write-up!

[Automation Monitor App]

Thanks