Does n8n alert you if a workflow stops running?

Not by itself. n8n's error workflow runs when an execution fails, so a workflow that is deactivated or never triggered produces no failure and no alert. You need an outside heartbeat check to catch that case.

Is Healthchecks.io free?

The Hobbyist plan is $0 a month and monitors 20 jobs with 100 log entries per job. One lead pipeline usually needs two checks, one for the live workflow heartbeat and one for the canary.

What is a dead man's switch in automation?

It is a check that alerts when an expected signal stops arriving, rather than when an error is reported. Your workflow pings a URL on every successful run, and the monitor raises an alert once the ping is overdue past its grace time.

n8n lead pipeline monitoring: a 2-hour plan

n8n lead pipeline monitoring starts with one question: if lead intake stopped right now, what would tell you? Usually it is a customer asking why nobody called back, or nothing at all.

Does n8n alert you when a workflow does not run?

Not on its own. An error workflow set in Workflow Settings runs when an execution fails, starting with the Error Trigger node: a node throwing, a credential expiring. It does not cover the run that never happened: no execution, no alert. The Error Trigger reference notes that execution.id and execution.url go missing when the error sits in the trigger node itself, since the workflow never executes.

So the watcher lives outside n8n, watching for silence.

What a dead man's switch does

It inverts the alert: instead of waiting for an error, you expect a heartbeat and alert when it stops. Healthchecks.io listens for pings, stays quiet while they arrive on time, and alerts the moment one is not.

Grace time matters: a job on 10 * * * * with five minutes of grace goes Late at 13:10 and Down at 13:15, when the alert fires. The Hobbyist plan is $0 a month for 20 jobs with 100 log entries each.

How to set up n8n lead pipeline monitoring in 2 hours

These minutes are my own estimate, for someone who already knows their workflow.

Pick the liveness signal, about 15 minutes. State it as a business outcome, like "a lead reached the CRM and got an owner," not "n8n is up."
Create the check and set grace, about 20 minutes. Period is your intake rhythm; grace is how long you can stand silence.
Ping from the workflow, about 25 minutes. Add an HTTP Request node at the end of the successful path, pointing at https://hc-ping.com/<uuid>. It takes HEAD, GET or POST.
Add a canary lead, about 35 minutes. A scheduled workflow pushes one tagged fake lead through the real intake path, reads it back, and pings success or fail. Purge canary records weekly.
Keep the n8n error workflow, about 15 minutes. For loud failures you still want the message. The Stop And Error node fails on purpose when a payload is wrong, turning a silent bad write into a reported one.
Name the owner, about 10 minutes. One person, one channel, one line of runbook. An alert nobody owns is a second silence. If unsure, start with an audit that finds the owner of every workflow.

Total: 120 minutes.

What each failure mode actually trips

Failure	Error workflow fires?	What catches it
A node throws mid-run	Yes	Error workflow, node named
CRM credential expired	Yes	Error workflow on the write step
The trigger node itself errors	Partly, less data, no `execution.id`	Error workflow plus the heartbeat
Workflow deactivated, host down, queue stalled	No	Heartbeat going Down after grace time
Runs fine, writes to the wrong field	No	Canary lead, read back end to end

The bottom two rows are the ones that cost money, and neither is an error.

What the silence costs you

Use your own numbers: leads a day times hours of silence, divided by 24. At 12 leads a day and 30 hours of silence that is 15 leads, and at a one-in-eight close rate, about 2 jobs you never knew existed.

Two hours of build against $0 a month on the free tier makes this a scheduling problem, not a budget one. Speed matters for the same reason: lead response loses on latency, not wording.

Limitations

A heartbeat proves the workflow finished, not that the data is correct. Only the canary tests correctness.
The canary writes real records through a real path. Tag and delete them, or your reports drift.
Grace time is a tradeoff: short grace pages you for a slow API, long grace buys hours of loss.
None of this recovers leads already dropped. A retry queue is a separate build, and so are guardrails before an agent writes to the CRM.

My take

Do the heartbeat today: about an hour, no new tools, and it closes the failure mode nobody is watching. Put the canary on next week's calendar: it catches a pipeline that looks healthy but writes to the wrong place.

If you are still deciding whether to run intake through n8n at all, the honest cost picture is what a business pays for bolting n8n onto its CRM. Monitoring belongs in that estimate, not after it.