PulseProbe

Automation monitoring guides

n8n guide

How to Get Alerted When an n8n Workflow Does Not Trigger

n8n is flexible enough to run scheduled workflows, trigger-based workflows, and self-hosted automation. That flexibility also means a workflow can fail to run for reasons that are not the same as a normal execution error.

Short answer

For n8n workflows that should complete on a schedule, add an HTTP Request node at the final successful path. If PulseProbe does not receive the heartbeat in time, it alerts you that the workflow missed its expected check-in.

Last reviewed: June 10, 2026PulseProbe is not an official n8n integration or partner. It uses a standard HTTP check-in from workflows that can make outbound HTTP requests.

Why an n8n workflow may not trigger

Scheduled workflows depend on their schedule configuration, published state, timezone settings, and the runtime that executes them. Self-hosted n8n setups also depend on the host, queue, workers, and network paths being healthy.

If the workflow never starts, an error workflow may not be enough by itself because there may be no failed execution to attach to.

Error Workflows vs missed-trigger monitoring

n8n Error Workflows are useful when another linked workflow fails during execution. Heartbeat monitoring is useful when the workflow never reaches the final success path or does not trigger when expected.

Step-by-step setup

  1. 1Create a PulseProbe probe for the n8n workflow.
  2. 2Set the expected interval to match the workflow schedule or expected completion cadence.
  3. 3Copy the heartbeat URL from PulseProbe.
  4. 4Add an HTTP Request node near the end of the workflow, after the important work completes.
  5. 5Use the heartbeat URL as the request URL. A simple GET request is enough for PulseProbe.
  6. 6Run the workflow manually or wait for the schedule, then confirm the probe shows a recent check-in.

Monitor the workflow level and the host level separately

A heartbeat at the end of a workflow tells you that a specific automation completed. It does not prove every n8n worker, queue, database, or host-level service is healthy.

For self-hosted n8n, pair workflow heartbeats with normal infrastructure monitoring for the server or container runtime.

Common mistakes

  • Putting the HTTP Request node before the nodes that actually matter.
  • Forgetting that a Schedule Trigger workflow must be saved and published to run automatically.
  • Using one heartbeat for multiple workflows with different schedules.
  • Treating workflow-level heartbeat monitoring as server uptime monitoring.

How to test the setup

  1. 1Run the workflow manually and confirm the HTTP Request node succeeds.
  2. 2Verify the PulseProbe probe shows a recent check-in.
  3. 3Safely disable or pause the workflow in a non-critical window.
  4. 4Wait for the expected interval plus grace period and confirm a missed alert.
  5. 5Re-enable the workflow and confirm recovery after the next successful run.

When not to use PulseProbe

  • Do not use heartbeat monitoring as the only control for safety-critical, medical, emergency, financial trading, or regulated systems.
  • Do not send secrets, customer records, prompt text, API keys, or private payloads to the heartbeat URL.
  • Heartbeat monitoring proves a check-in arrived. It does not inspect the quality of the workflow output.

FAQ

Can n8n Error Workflows catch missed triggers?

They are designed for workflow execution errors. If the workflow never starts or never reaches the final success path, a heartbeat monitor gives a different outside signal.

Where should I put the HTTP Request node?

Near the end of the success path, after the nodes that perform the important work.

Does this monitor my n8n server?

No. It monitors workflow completion. Use infrastructure monitoring for the host or container running n8n.