Your n8n workflow stopped silently. What detects the execution that never starts?

Use three controls, not one

An in-instance watchdog has the same failure domain as the workflow it watches. If the n8n scheduler or host is down, both can stay silent. Use an independent external expectation for instance-level outage detection.

1. Write the heartbeat contract

Start with one workflow and one observable result. Do not use “the workflow usually runs” as the contract.

workflow_id:
expected_cadence:
timezone:
success_evidence:
heartbeat_emitted_after:
maximum_normal_duration:
grace_period:
overdue_at:
alert_destination:
recovery_signal:

Emit the heartbeat only after the required business outcome is verified. A heartbeat immediately after the trigger proves that the workflow started; it does not prove that the record, message, payment, file, or CRM state changed.

2. Pick the right state boundary

n8n data tables can persist structured markers across workflows in the same project. A target workflow can upsert its latest successful outcome timestamp, and a separate scheduled workflow can read that row and classify it as fresh or overdue.

• Use one stable row key per watched workflow and environment.
• Store the last verified success time, expected cadence, grace, and a non-sensitive correlation ID.
• Do not store credentials, raw payloads, customer data, or authorization headers in the heartbeat row.
• Use an upsert so one workflow does not create an unbounded row on every run.

This pattern detects missing or incomplete outcomes while n8n is still healthy. It does not replace an external liveness monitor for the n8n host, scheduler, database, or network.

3. Set the deadline from observed behavior

Make the threshold large enough for normal jitter and small enough for the business recovery window. Record the rule explicitly:

overdue_at =
  last_verified_success
  + expected_cadence
  + maximum_normal_duration
  + grace_period

• A five-minute workflow should not alert at five minutes and one second.
• A daily workflow needs an explicit timezone and daylight-saving decision.
• A polling trigger needs a qualifying new upstream event; “no event” is not automatically a failure.
• A business-hours workflow needs a calendar rule rather than a continuous interval.

n8n's Schedule Trigger relies on the workflow timezone when set and otherwise the instance timezone. Schedule edits and variable-based cron changes take effect only after the workflow is republished.

4. Keep the external ping secret-free

For instance-level monitoring, send a minimal success ping to an independent service after the verified outcome. Treat a unique ping URL as a bearer credential even when the provider calls it a “simple URL.”

• Keep the ping URL in an n8n credential or protected environment value.
• Send no source payload, customer record, token, stack trace, or private callback URL.
• Use separate identities for test and production.
• Require the external monitor—not n8n itself—to decide that the heartbeat is late.
• Route alerts through a destination the operator controls and has tested.

5. Dedupe the alert and prove recovery

A watchdog that sends the same alert every minute becomes another outage. Track incident state separately from heartbeat state.

1. Open one incident when the heartbeat first crosses the overdue threshold.
2. Suppress repeats while that incident remains open.
3. Escalate only at a documented second threshold.
4. Close the incident after a new verified-success heartbeat.
5. Emit one recovery signal containing only identifiers and timestamps.

Do not auto-replay irreversible work merely because a heartbeat is late. First determine whether the source event was absent, delayed, partially processed, or processed without recording the heartbeat.

6. Run a controlled failure drill

1. Use a test workflow or an approved maintenance window.
2. Record the last verified-success heartbeat and expected overdue time.
3. Prevent one expected run without deleting its state or credentials.
4. Verify exactly one overdue incident at the expected threshold.
5. Restore the workflow and publish it if the trigger requires publication.
6. Produce one new verified business outcome.
7. Verify the heartbeat advances and exactly one recovery signal appears.

Test the Error Trigger separately by creating a safe automatic failure. n8n documents that error workflows do not run during a manual workflow test, so a green editor exercise is not production proof.

Official n8n references

• Error Trigger behavior and error data ↗
• Data tables overview and limitations ↗
• Data Table row get and upsert operations ↗
• Schedule Trigger publication and timezone behavior ↗
• Schedule Trigger common issues ↗

The separate external-monitor recommendation is an architectural inference from failure-domain isolation, not an n8n product claim. Agent Rescue Desk is independent and is not affiliated with, endorsed by, or sponsored by n8n.