My n8n workflows stopped and nothing alerted me

Error workflows and watchdog workflows run on the n8n instance they watch. When the instance is down, its scheduler has stalled or its queue workers are gone, they stop too, and the silence looks exactly like a quiet day.

The pattern is familiar from r/n8n and the n8n forum: someone notices on a Monday that a report never arrived, opens n8n and finds that nothing has run since Thursday. No error workflow fired, the watchdog template sent nothing, and the uptime check stayed green. Each of those was working as designed. They all live on the instance that stopped.

What stops everything at once

The instance is down. The host rebooted and the container did not come back, an update failed to start, the disk filled, or the database it needs is unreachable. Nothing runs, and that includes every workflow that was meant to tell you.
The scheduler stalled. The process is up and the editor opens, but Schedule Triggers stopped firing: workflows that failed to activate when the instance started, or runs due during a redeploy that were skipped without a record. n8n Schedule Trigger not firing goes through the causes one by one.
The queue workers are gone. In queue mode the main process receives triggers and webhooks and puts each execution on a Redis queue for workers to run. If every worker has crashed, been scaled to zero or lost Redis, executions wait and none finish, while the main process still answers /healthz with 200. Workers have their own /healthz only when QUEUE_HEALTH_CHECK_ACTIVE=true is set on them.

Why the alerts you set up stayed quiet

The error workflow runs when an automatic execution fails. With no execution there is no failure, and in queue mode the error workflow is itself an execution that needs a worker.
A watchdog workflow, such as the free templates that check your workflows through the n8n API every hour and alert on no runs, errors or empty output, is good at catching one workflow that went quiet while the rest of n8n is healthy. It runs on a Schedule Trigger on the same instance, so when the instance, its scheduler or its workers stop, it stops too.
An uptime check on /healthz proves the main process answers. It does not prove that a trigger fired or that a worker ran anything.

All three report on something that happened. None of them can report from a place where nothing is happening.

The check that lives outside n8n

Turn it around: have n8n tell something outside it that work finished, on every run, and treat silence past a deadline as the alert. The outside service does not care why the ping stopped, so a dead host, a stalled scheduler and a missing worker all look the same: a ping that did not arrive.

One heartbeat for the instance. A small workflow with a Schedule Trigger every five minutes and one node that pings a monitor with a period of 5m. It goes through the scheduler and, in queue mode, a worker, so it alerts within minutes when any of the three stops.
One heartbeat per workflow that matters. A ping as the last node on the success path, with the workflow's own schedule as the monitor's period. That tells you which workflow went quiet when the instance is fine.
The error workflow reports too. After the Error Trigger, a ping to the monitor's /fail URL, so a run that starts and breaks alerts at once with the error attached.

The ping is the Vivere node with Ping → Success, or an HTTP Request node:

Method: POST
URL:    https://vivere.dev/p/<your-monitor-id>

Set each monitor's grace from the workflow's slowest normal run; the grace period calculator works it out. Keep the in-n8n watchdog if you have one: it notices an empty result or a single workflow being unpublished, and the outside heartbeat notices when n8n itself has gone quiet.

Vivere's free plan covers 25 monitors with alerts by email or webhook, which is enough for the instance heartbeat and the workflows you would miss first. The n8n guide has the setup step by step, and a free account takes about a minute and opens on the instance heartbeat, already filled in.

Common questions

Why didn't my n8n error workflow fire when everything stopped?

An error workflow is itself an execution on the same instance. It runs when another execution fails, so it needs an execution to fail and an instance able to run it. When the host is down, the scheduler has stopped or no worker is taking jobs, there is neither, and the error workflow stays as silent as everything else.

Can an n8n watchdog workflow catch an instance that is down?

No. A watchdog that checks your other workflows through the n8n API, or looks for the row they should have written, runs on a Schedule Trigger on the same instance. It catches one workflow that went quiet while the rest of n8n is healthy. When the instance, its scheduler or its workers stop, the watchdog stops with them and has nothing to send the alert from.

Is an uptime check on n8n's /healthz enough?

It tells you the main process answers HTTP. In queue mode the main process takes triggers and webhooks and hands executions to workers through Redis, so /healthz can answer 200 while every worker is gone and executions wait unprocessed. It also says nothing about whether the scheduler fired. A ping sent from the end of a workflow proves the whole path ran.

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 November 2026.

How to get an alert when an n8n workflow doesn't run — n8n tells you when a workflow fails, not when it does not run: an unpublished workflow, a schedule lost to a restart, a webhook nobody calls, an instance that is down. What n8n offers on its own, where each part stops, and the dead man's switch that covers the rest.
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.