How to monitor an n8n workflow that fails silently

n8n is good at telling you when a run breaks. It can't tell you about a run that never happened, or one that finished "successfully" with nothing in it. This guide shows how to catch every kind of failure with one HTTP Request node, one Error Trigger workflow and a heartbeat monitor.

Updated October 31, 2026 · Written against the current n8n docs (publish-based workflows) · 10-minute read

What n8n's Error Workflow catches, and what it misses

In n8n, each workflow can name an Error Workflow in its settings. That workflow must start with an Error Trigger node, and it runs when an execution of the monitored workflow fails. It's the right tool for loud failures: a node throws, an API returns a 500, the workflow runs out of memory.

It has three blind spots worth knowing:

• Manual runs don't trigger it. The Error Trigger only runs when an automatic (production) execution errors, so clicking Execute Workflow in the editor won't test it.
• No execution, no error. If the workflow didn't run at all, there's nothing to fail and the Error Workflow stays quiet.
• "Success" isn't always success. If a node is set to On Error: Continue, or an API happily returns zero rows, the execution finishes green.

Here's how those blind spots show up in practice:

A heartbeat covers the first six rows, because they all look the same from the outside: the "I finished, here's what I did" check-in never arrives, or arrives with a count of 0.

Check a workflow right now

If you think a workflow has gone quiet, check these in order:

1. Is it published? On the Workflows page, published workflows show an indicator on their card. In the editor, a Publish button showing Published, has changes means your latest edits aren't live yet.
2. Is it executing? Open the workflow's executions list (or the all-executions list) and look for runs at the times you expect. A gap means the trigger didn't fire or the instance wasn't running.
3. Are executions being saved? In Workflow Settings, Save failed production executions and Save successful production executions control what shows up in that list. If they're off, an empty list proves nothing.
4. What did the last run produce? Open the most recent execution and check the item count on the node that fetches your data. A run that processed 0 items is a silent failure, even though it's green.
5. Is the time zone right? Check Timezone in Workflow Settings, and the instance time zone (GENERIC_TIMEZONE when self-hosted).

That tells you what happened this time. The rest of this guide makes sure you're told next time, without having to look.

Set it up: heartbeat plus Error Trigger

You'll need a ping URL from a monitor that runs outside your n8n instance. A check that lives inside n8n goes down with it. The examples use a Pulsecheck URL like https://pulsecheck.run/p/YOUR-JOB-ID, but the n8n side works the same with any heartbeat service.

1. Create a monitor that matches the schedule

Match the monitor's period to the Schedule Trigger: a workflow that runs every hour gets a 1-hour period. Set the grace period to the longest normal run plus a margin, for example 10 minutes for a workflow that usually takes 3. If you run interval schedules, remember they count from when the workflow was published, not from the top of the hour.

2. Add a heartbeat HTTP Request node at the end

Add an HTTP Request node as the last node on the path that means "done". Placement matters: at the end, the ping proves the whole workflow ran. Straight after the trigger, it only proves the workflow started.

Node: HTTP Request  (rename it "Ping Pulsecheck")
  Method:             POST
  URL:                https://pulsecheck.run/p/YOUR-JOB-ID
  Send Body:          on
  Body Content Type:  JSON
  Specify Body:       Using JSON
  JSON:               {"count": {{ $('Get new leads').all().length }} }
  Options → Timeout:  10000

Settings tab:
  Execute Once:   on        (one ping per run, however many items arrive)
  Retry On Fail:  on
  On Error:       Continue  (a failed ping never fails a good run)

Replace Get new leads with the name of the node whose output you want to count. $('Node name').all() returns that node's output items, so .length is how many it produced. Execute Once makes the node run a single time with the first item it receives, so you get one ping per run rather than one per item.

3. Keep the ping running on empty days

On the node before the ping, open the Settings tab and turn on Always Output Data. The node then returns an empty item even when it has no data, so the ping still runs and reports what actually happened (a count of 0) instead of going silent. Be careful turning this on for IF nodes; n8n warns it can cause an infinite loop there.

4. Report failures with an Error Trigger workflow

Create a separate workflow that starts with an Error Trigger, followed by an HTTP Request node that calls the same ping URL with /fail on the end:

Workflow: "Pulsecheck error handler"

1. Error Trigger

2. HTTP Request
   Method:             POST
   URL:                https://pulsecheck.run/p/YOUR-JOB-ID/fail
   Send Body:          on
   Body Content Type:  Raw
   Content Type:       text/plain
   Body:               {{ $json.workflow.name }} failed at {{ $json.execution.lastNodeExecuted }}: {{ $json.execution.error.message }}

Then open the workflow you're monitoring, choose Settings from the workflow menu, set Error Workflow to "Pulsecheck error handler", and save. A failed production execution now reports straight away instead of waiting for the heartbeat deadline. Pulsecheck shows what you sent alongside the alert, so you know which node broke without opening n8n.

One detail from the n8n docs: if the error happens in the trigger node itself, the Error Trigger receives the details under trigger.error rather than execution.error, and there's no execution ID or URL. Your message will be thinner in that case, but the /fail call still arrives.

5. Catch runs that succeed with nothing to show

You have two options, and they work well together:

• In Pulsecheck: because the ping carries {"count": ...}, add an output rule such as count at least 1. A run that pings with 0 is flagged as Ran but output looks wrong, even though n8n says it succeeded. (Output checks are on the Pro and Agency plans. Missed-run and /fail alerts work on every plan, including the free one.)
• In n8n: add an IF node that checks the count and routes the empty case to a Stop And Error node. That turns "no data" into a real failed execution, which your Error Workflow then reports.

Get new leads  →  IF  {{ $('Get new leads').all().length }} is greater than 0
                      ├─ true  → ...rest of workflow... → Ping Pulsecheck
                      └─ false → Stop And Error  (Error Message: "No new leads today")

Use the n8n route when an empty result is always wrong. Use the output rule when you'd rather keep the workflow simple and set the threshold in one place.

6. Bound hangs with Timeout Workflow

In Workflow Settings, turn on Timeout Workflow and set Timeout After comfortably above the longest normal run. A stuck execution is cancelled instead of holding things open. Either way, the heartbeat never arrives, so the monitor alerts you once the grace period is up. (n8n Cloud plans have a maximum timeout.)

7. Publish and test both paths

1. Publish the workflow. Schedules only run for the published version.
2. Run it once from the editor. The heartbeat node sends a real request, so the monitor should turn green with your count.
3. Test the failure path with a production execution, since manual runs don't trigger the Error Trigger. For example, temporarily point a node at a URL that doesn't exist, set the schedule to every few minutes, publish, and wait for the /fail alert. Then put everything back and publish again.
4. Finally, unpublish it (or let a run be missed) and confirm the missed-run alert reaches you.

Monitoring many client workflows

If you run n8n for clients, the setup scales with a few habits:

• One monitor per workflow. A shared URL lets a healthy workflow mask a dead one. Name monitors Client · Workflow so alerts make sense at a glance.
• One shared error workflow. n8n lets many workflows use the same error workflow. Add a Switch node on {{ $json.workflow.id }} and send each branch to the right /fail URL.
• Event-driven workflows too. For webhook or app-event triggers that should fire "at least once a day", set the monitor's period to the longest normal gap between runs.
• Send counts, not data. The ping is a status signal. Send item counts and field names, never client records or credentials.

Common mistakes

• Testing the Error Workflow with a manual run and concluding it's broken. It only fires for automatic executions.
• Putting the ping straight after the trigger. It proves the workflow started, not that it finished.
• Leaving the ping on its default error behavior. If the monitor is briefly unreachable, a ping without On Error: Continue fails a run that was otherwise fine.
• Pinging once per item. Without Execute Once, 200 items means 200 pings.
• Forgetting to republish. Moving the ping node or changing the schedule doesn't take effect until you publish the new version.
• Running the monitor inside n8n. A "watchdog" workflow on the same instance can't report that the instance is down.
• Ignoring time zones. A self-hosted instance with no time zone set runs schedules on New York time.

FAQ

Does n8n alert me when a workflow stops running?

Not by itself. An Error Workflow runs when an execution fails. If the workflow isn't published, the instance was down, or the schedule never fired, there's no execution to fail, so nothing runs. A heartbeat monitor outside n8n catches those cases because it's waiting for a check-in that never arrives.

Why didn't my n8n error workflow fire?

The usual reasons: you ran the workflow manually (the Error Trigger only runs when an automatic execution errors), the failing node is set to On Error: Continue so the execution counted as a success, the monitored workflow's Error Workflow setting points somewhere else, or the workflow never executed at all.

Can one error workflow handle all my n8n workflows?

Yes. n8n lets you pick the same error workflow in many workflows' settings. To report each one to its own Pulsecheck monitor, branch on {{ $json.workflow.id }} with a Switch node and send each branch to the matching /fail URL.

Will the heartbeat ping slow down or break my workflow?

It's one HTTP request at the end. Set a timeout on the node, turn on Retry On Fail, and set On Error to Continue, so a network blip on the ping never turns a good run into a failed one. If a ping is lost, the monitor alerts after the grace period rather than instantly.

Does this work on n8n Cloud and self-hosted n8n?

Yes. The heartbeat is an ordinary outbound HTTPS request from an HTTP Request node, so it works anywhere the workflow can reach the internet.

What happens to scheduled runs while my n8n instance is down?

On recent versions, the Schedule Trigger's If Execution Is Missed setting decides. The default, Don't Run Missed Executions, discards them and resumes on schedule. You can choose to run the most recent missed execution instead. Either way, a heartbeat tells you a run was missed.

Related: How to know if your AI agent stopped running · all Pulsecheck guides. n8n settings and behavior described here follow the official n8n documentation at docs.n8n.io as of October 31, 2026; labels can differ slightly between n8n versions.