How to tell when an n8n workflow stops running

n8n's mechanism for failures is the Error Workflow, driven by the Error Trigger node. You set it per workflow, and n8n runs it when an automatic execution fails, for example when a node throws or the execution runs out of memory. It is genuinely useful for what it covers.

What it covers is failures during an execution. The trigger fires because an execution started, got somewhere and broke. If no execution ever starts, there is no failure event, so the Error Workflow is never invoked. The same limitation shows up in n8n's own documentation of the edge case: when the error is in the trigger node of the main workflow, the error data is not populated, because the workflow did not execute.

So the entire class of problem where nothing happened is invisible to it. That class is larger than it first appears:

• The workflow was deactivated, by you months ago or by someone else last week, and nobody noticed the toggle.
• A Schedule Trigger stopped firing. The workflow is still active and still looks healthy in the editor.
• A self-hosted instance restarted, ran out of disk, or came back up with the queue worker not running.
• An upstream webhook provider stopped calling, so a webhook-triggered workflow simply has nothing to react to.

In every case the workflow is not erroring. It is absent. Error notifications are the wrong shape of instrument for absence.

The Executions list is the honest record of what ran. It is also strictly a record of what ran: a workflow that stopped a week ago has a week-old last execution and no other signal. Finding that requires you to go and look, which means the detection interval is however often you happen to check. That is fine for a workflow you open daily and useless for the twenty you do not.

An Error Workflow plus a notification node is worth setting up, and you should. It shortens the time to hear about the failures it can see. It does not widen the set of failures it can see.

Adding a heartbeat inside n8n — a second workflow that checks the first — moves the problem rather than solving it. The checker is itself an n8n workflow on the same instance, subject to the same deactivation, the same restart and the same trigger failure. When the instance goes down, both go down, and the silence is total.

The thing that has to live outside n8n is the expectation. Something needs to hold the belief “this workflow reports in every fifteen minutes” somewhere that is unaffected by n8n being broken.

Invert the direction of the check. Instead of something asking n8n whether it is healthy, the workflow reports in each time it finishes. A timer elsewhere is reset by each report. If the timer runs out, the report did not arrive, and that is the alert.

The useful property is that it makes no assumptions about why the workflow stopped. Deactivated, crashed, never triggered, instance dead, node hung on a slow API — all of them produce the same observable, which is silence, and silence is exactly what the timer is watching for.

Add an HTTP Request node as the last node of the workflow and connect it to the final step of the path you consider “done”. Set the method to GET and the URL to the ping URL for that monitor:

Each monitor has an expected interval and a grace period, and the deadline is the last ping plus both. The grace period defaults to twice the interval, which is deliberately generous: a workflow that occasionally runs a few minutes late should not page you, and a monitoring tool that cries wolf gets muted, at which point it is worse than nothing.

Past the deadline you get one email. Exactly one, for the whole outage, however long it lasts and however many times the checker runs while it is open. When pings resume you get one all-clear, and only then does the monitor become eligible to alert again. Two emails per outage total.

If the workflow runs on a daily schedule rather than an interval, the deadline is a wall-clock time in your account's own timezone, so “daily by 09:00” means 09:00 where you are, including across daylight-saving changes.