n8n

A Schedule Trigger that stops firing produces no failed execution, so your Error Workflow never reports it. Here is the check that does.

An Error Workflow fires when an execution fails, which means an execution has to exist first. A Schedule Trigger that does not fire produces no run at all, so nothing fails, and the notify node you put on the error branch has nothing to report. It covers a workflow that ran and broke. It cannot cover a workflow that never started.

That happens in three common shapes. The instance was restarting, redeploying or being updated at the scheduled minute, and unless the newer durable scheduler is turned on and set to catch up, n8n neither runs it late nor records that one was skipped. The workflow was not active, after an import, a restore from a backup, or a cluster of trigger errors that switched it off. Or the trigger is firing on a timezone or a cron expression that is not the one you are thinking in, so the run lands at an hour nobody is watching. The full list runs to six.

If you already check with a second workflow

The usual hand-built answer is a second Schedule Trigger on a deliberately different cadence, looking for the row the daily workflow should have written today. That is a good design, and the different cadence is the right instinct, because a restart that lands on one schedule is unlikely to land on both.

The gap in it is where it runs. Both workflows are timers inside the same n8n process, so a host that is off, a deploy that hangs, or a container that does not come back takes the checker away along with the thing it was checking. The rest of this page is that same check, run from outside your instance.

Use the Vivere node

The demo on YouTube (5:43): installing the node, creating a monitor, reporting runs from a workflow and from an AI Agent, and how Vivere alerts you. It opens on YouTube; nothing from YouTube loads on this page.

The Vivere node for n8n does the steps below for you. It is a verified community node, so on n8n Cloud you search for Vivere in the nodes panel and add it from there (an instance owner may need to turn on verified community nodes in the Admin Panel first). On a self-hosted n8n, install n8n-nodes-vivere under Settings → Community Nodes. Then add a key from API keys as its credential, and put a Vivere node with Ping → Success after the last step. It sends one ping per run however many items reach it, records how many items the run handled, and can report a run that handled none as failed. Ping → Fail goes on the error branch or in your Error Workflow, and Monitor → Create makes the monitor from n8n. The example workflow has all three pings.

Without the community node, an HTTP Request node does the same job.

Add an HTTP Request node as the last step

1. Add an HTTP Request node after the final node of the scheduled workflow.
2. Method POST, URL https://vivere.dev/p/<monitor-id>.
3. Optional: under Body choose Raw, content type text/plain, and send an expression such as {{ $json.summary }} to keep it as the run log.
4. Optional: add a query parameter items with the expression {{ $input.all().length }}, and turn on Settings → Execute Once so the node pings once rather than once per item. Every run then records how many items it handled. A run that usually handles 400 rows and handled 0 went through without failing, and the run list makes that easy to see.
5. Set Settings → On Error to Continue so a ping failure never fails the workflow.

Start from a ready-made workflow

Two workflows built from core nodes only, so they need nothing installed. In n8n, open a new workflow, choose Import from URL in the workflow menu and paste one of the links below, or download the file and use Import from File. Sticky notes in each walk through the setup, and the only value to fill in is the ping URL in its Config node.

• Alert on failed or empty scheduled runs: pings at the start, then success with the item count, or a failure when the run handled nothing or a step errored. Its example step has Always Output Data turned on, because without it an empty result stops the run before anything can report it.
• Watchdog for a self-hosted instance: runs every 5 minutes inside your instance and reports failed executions from n8n's own API. When the instance stops, so do its pings, and that silence is what Vivere alerts on. It needs an n8n API credential.

Two more that do real work and use the Vivere node, so they need n8n-nodes-vivere installed (on n8n Cloud it is in the nodes panel). Set the values in each Config node and add the credentials the sticky notes name.

• Back up every workflow to GitHub: every night, reads all workflows through the n8n API and writes each to a GitHub repository as its own file, creating new ones, updating changed ones and leaving the rest alone, so the history shows only real edits. The success ping carries the number of workflows and the list of changed files; a file GitHub refuses sends a fail ping.
• Label new GitHub issues with OpenAI: every hour, asks an OpenAI model to label the issues nobody has labelled yet, using only labels from your list. Each run reports the model, tokens and cost, so a cost alert on the monitor catches a run that costs more than it should.

Report failures from the Error Workflow

The Error Workflow still earns its place for the runs that do happen and break. Add an HTTP Request node to https://vivere.dev/p/<monitor-id>/fail with the error message as the body, and the monitor goes Down at once with the message attached rather than waiting out the deadline.

Monitor settings

Use the same schedule as the trigger. A workflow on Every hour is period 1h, grace 10m. A cron schedule such as 0 6 * * 1-5 should be entered as a cron expression on the monitor, with the instance's timezone.

Treat grace 10m as a placeholder rather than a recommendation. A loaded instance starts a workflow minutes after its scheduled time, so the number you want is the workflow's worst normal run plus that delay plus a margin. Set it too tight and the first slow night pages you, which is how a monitor ends up muted. The calculator takes those and gives you a figure, and n8n is one of the schedulers it knows the delay for.