A workflow that fails gets a red icon in the executions list, and if you've wired up error handling, a Slack message too. That's the failure everyone plans for. The one almost nobody plans for is the workflow that just stops — deactivated by an accidental toggle, a schedule trigger that quit ticking, a credential that expired on the trigger step instead of somewhere downstream. No execution runs. No red node. Nothing in n8n points at the problem, because from n8n's point of view, there's nothing to look at.
A different kind of quiet than "ran green, did nothing"
We've written before about workflows that execute successfully and still accomplish nothing — an empty IF branch, a Continue On Fail setting swallowing an error, a Merge node dropping rows. Those are failures inside a run that actually happened. This is the failure one step earlier: the run that never starts. Different cause, same blind spot, and arguably a worse one — a green-but-empty execution at least shows up in the log. A workflow that's stopped triggering altogether doesn't generate anything to find it by.
Three ways a workflow goes quiet
Someone turns it off without meaning to
Open a workflow to fix one node, save, and the active toggle doesn't always survive the edit the way you'd expect. Or a teammate flips it off to test something and forgets to flip it back on. n8n's workflow list does show active and inactive status plainly. Almost nobody checks that list on a daily basis, though, so the deactivation sits there, visible and ignored, until someone notices the thing it was supposed to do stopped happening.
The schedule stops matching reality
A Schedule Trigger set against a specific timezone keeps ticking through a daylight saving shift fine on n8n Cloud. Self-hosted instances running on a server with their own timezone configuration are where this gets messy — a cron expression that meant 9am before a DST change can mean 8am or 10am after, and nothing errors. The workflow still runs. It just runs at the wrong time, or at a time nobody downstream is expecting, which for most business logic is close enough to not running at all.
A credential expires on the trigger, not the action
Most people picture credential expiry breaking an HTTP Request node mid-run, which at least produces a red node. A Gmail or Google Sheets polling trigger that loses its OAuth refresh token behaves differently — the trigger can't check for new events, so the workflow never gets invoked in the first place. No execution, no error, no clue beyond "huh, new leads stopped showing up a while back."
Why the executions list can't help you here
n8n's monitoring surface — the executions tab, error workflows, retry settings — all watch executions that already exist. That's the entire category of thing it tracks. A workflow that's stopped triggering never produces an execution to watch in the first place. You can stare at a perfectly clean, zero-errors executions list for a workflow that hasn't actually run in two weeks, because clean and empty look identical from inside a tool that only records what already happened.
The absence of a bad execution and the absence of any execution look exactly the same from inside n8n. Something outside it has to be the one telling them apart.
The fix: a heartbeat that something else keeps time on
The pattern doesn't require new infrastructure if you've already got a database or a sheet n8n can write to. Every workflow worth watching writes one row to a shared heartbeat table the moment it starts — workflow name, a timestamp, and the interval you expect between runs. A separate watchdog workflow, on its own schedule, reads that table and checks each row's timestamp against its expected interval times a grace multiplier, usually 1.5 to 2x. Anything older than that gets a Slack message naming the workflow and how long it's gone quiet.
The grace multiplier matters more than it looks like it should. Set it to exactly 1x and you'll get paged every time a run lands a few minutes late from queue backlog or a slow upstream API — real noise that trains everyone to ignore the alert within a week. A daily workflow expected at 9am with a 1.5x grace window doesn't complain until 36 hours of silence, which is late enough to rule out ordinary jitter and still early enough that you're not finding out a week after the fact.
Where this pattern runs out
It works cleanly for anything on a schedule — daily reports, nightly syncs, a reminder workflow that fires every morning. It doesn't translate directly to a webhook-triggered workflow with no fixed cadence, like a lead form that gets submitted whenever someone happens to fill it out. There's no expected interval for something event-driven by nature. The closest equivalent is a volume baseline — comparing this week's submission count against a rolling average and flagging a drop toward zero — which is a looser signal built differently, not a drop-in swap for the heartbeat table. Worth knowing before you try to bolt one pattern onto every workflow in your account.
If a database isn't already part of the setup, the same idea exists as a hosted dead man's switch — the monitored workflow pings a URL at the end of each run, and a service outside your n8n instance holds the timer and fires the alert if the ping doesn't show up. Healthchecks.io and Cronitor both work this way. The advantage over a self-built heartbeat table is that the thing doing the watching isn't running on the same infrastructure that might be the reason your workflow went quiet to begin with.
Either way, the point stands. Something that isn't the workflow has to be the one keeping time on it. We build that watchdog layer into client automations by default now — a few hours of setup against the alternative, which is a client asking why nobody called them back, three weeks after the lead-routing workflow quietly stopped.
— Cole