How to get an alert when an n8n workflow doesn't run

n8n's Error Trigger reports executions that fail. A workflow that never starts leaves no execution to fail, so that alert has to come from outside n8n.

n8n has a good answer to "tell me when a workflow breaks": an error workflow, started by an Error Trigger. It has no answer to "tell me when a workflow did not run", and the two are easy to confuse until the day a workflow turns out to have been silent for a week while the error workflow never made a sound.

What n8n can tell you on its own

Error workflows. Make a workflow that starts with an Error Trigger, then choose it under Error workflow in each workflow's settings. When an automatic execution of that workflow fails, the error workflow runs with the error message, the last node executed, the workflow's name and a link to the execution. It does not run for executions you start by hand in the editor, and it does not need to be published itself.
Stop and Error. A node that fails an execution on purpose, so a condition you care about, such as an empty result, reaches the error workflow too. Catching runs with 0 items shows how.
The executions list. Every execution that happened, with its status, and only those.
Health endpoints. /healthz answers 200 when the instance is reachable, and /healthz/readiness answers 200 when its database is connected and migrated. With N8N_METRICS=true, /metrics gives more detail about the instance.

Every one of these starts from something that happened: an execution that failed, an execution that was recorded, a process that answered. None of them notices an execution that should have happened and did not.

The runs that never start

These are the common ways a workflow goes quiet without an error anywhere:

The workflow is not published. Since n8n 2.0, Publish and Unpublish replace the old Active toggle, and only a published workflow's triggers run: its schedules fire, its production webhook URLs answer and app events start it. A workflow unpublished from the list by mistake looks almost the same as one that is running.
A schedule was due while the instance was restarting. By default a Schedule Trigger is a timer inside the n8n process, and a run due during a restart, redeploy or update is skipped without a record. n8n Schedule Trigger not firing covers that and five other causes.
Nobody calls the webhook. A Webhook trigger runs when something sends it a request. If the sender was reconfigured, is still calling the test URL rather than the production one, or is down itself, the workflow is fine and simply never asked.
The instance is down. The host is off, the container did not come back after an update, or the database is unreachable. Nothing runs, including the error workflow, which lives on the same instance.

In each case there is no execution, so nothing fails and the Error Trigger has nothing to fire on.

Why a second workflow on the same instance is not enough

The usual workaround is a watchdog workflow: a second Schedule Trigger that checks whether the first one ran, for example by looking for the row it should have written today. It catches the unpublished workflow and the webhook nobody called. It shares everything else with the workflow it watches: the same process, the same scheduler, the same host. A restart that drops one schedule can drop both, and an instance that is down runs neither. The check has to live somewhere the instance's failures cannot reach.

A dead man's switch at the end of the workflow

Invert the check. Instead of n8n reporting a failure, the workflow reports success to something outside n8n on every run, and silence past a deadline is the alert. Whatever stopped the run, whether an unpublished workflow, a lost schedule, a quiet webhook or a dead host, it looks the same from outside: the ping did not arrive.

Create a heartbeat monitor in Vivere with the workflow's schedule. A workflow on Every hour is a period of 1h; a cron schedule such as 0 6 * * 1-5 goes in as a cron expression with the instance's timezone.
Add a ping as the last node on the success path: the Vivere node with Ping → Success, or an HTTP Request node to the monitor's ping URL:
```
Method: POST
URL:    https://vivere.dev/p/<your-monitor-id>
```
Set the grace, how late the ping may be before it counts as missing, from the workflow's slowest normal run plus the delay before n8n starts it. The grace period calculator works it out.

Keep the error workflow, and have it report to the monitor too: an HTTP Request node to https://vivere.dev/p/<your-monitor-id>/fail, or a Vivere node with Ping → Fail, after the Error Trigger. A run that starts and breaks then alerts at once with the error attached, and a run that never starts alerts when the grace runs out.

A webhook workflow has no schedule to copy, so give its monitor a period as long as the longest normal gap between calls. For the instance itself, one workflow with a Schedule Trigger every five minutes that does nothing but ping its own monitor tells you within minutes that the host or the scheduler has stopped, while the monitors on individual workflows tell you which one went quiet.

On Vivere's free plan, which covers 25 monitors, alerts go to email or a webhook; paid plans add Slack, Discord, Telegram and ntfy. The n8n guide has the setup in full, with the Vivere node and with HTTP Request.

Common questions

Does the n8n Error Trigger fire when a workflow doesn't run?

No. The Error Trigger runs when an automatic execution of a workflow fails, so there has to be an execution first. A workflow that is not published, a schedule that was due while the instance was restarting, a webhook nobody called and an instance that is down all produce no execution, and so no error.

How do I check that my n8n instance is up?

n8n answers /healthz with 200 when the instance is reachable, and /healthz/readiness with 200 when its database is connected and migrated. An uptime check on those tells you the process is up. It does not tell you that any workflow ran: an instance can answer both while a workflow's trigger is not firing.

How do I monitor an n8n workflow that runs on a webhook, not a schedule?

Give its heartbeat a period as long as the longest normal gap between calls, plus a margin, rather than the average gap. A webhook called a dozen times a day that sometimes goes quiet overnight wants a period of a day, not an hour. If the quiet spells are too irregular for any period, watch the system that calls the webhook instead.

Find out without looking

Vivere watches for the ping that does not arrive. Add one line to the job, pick where alerts should land, and you hear about the run that never happened.

Start free Read the quickstart

25 monitors, a status page, email and webhook alerts. No card.

Last reviewed October 2026.

n8n Schedule Trigger not firing: what to check — Your n8n Schedule Trigger stopped running. Activation state, timezone, missed executions after a restart, queue mode, and how to be told when a workflow goes quiet.
n8n workflow succeeded but did nothing: catching runs with 0 items — An n8n execution says Success but handled no items: an empty API response, a Filter that dropped everything, a renamed field. Why n8n counts it as success, how to make it fail with Always Output Data, an If node and Stop and Error, and how a heartbeat can alert on a run that handled 0 items.
A dead man's switch for your scripts — What a dead man's switch is, why it catches failures that error-based alerting cannot, how to build one with cron and curl, and the timing rules that stop it crying wolf.