N8n polling trigger stops, heartbeat and watchdog fix

If your n8n polling trigger stops without errors, add a heartbeat plus watchdog pattern: have the polling workflow emit a regular ping to an external monitor and to an internal watchdog workflow, raise alerts when pings miss, and let the watchdog hit a companion webhook to restart or re-run the workflow automatically.

Why the n8n polling trigger stops

Polling triggers can stop silently for several reasons: transient network errors, upstream API rate limits or blocking, exhausted credentials, or a crash in a downstream node that prevents future executions. Sometimes the process manager for your n8n host restarts the service but not every workflow reactivates cleanly. The result is the same, your automation stops and no error shows in the workflow run list.

Production pattern: heartbeat plus watchdog when n8n polling trigger stops

Use two cooperating pieces: a heartbeat emitter inside the polling workflow, and a watchdog workflow that watches for missed heartbeats and recovers the polling workflow. Add external monitoring for alerts.

Heartbeat, inside the polling workflow: send a simple GET to a health check URL, or write a timestamp to a lightweight store (Google Sheets, Redis, or a small database).
External monitor: use a service like Healthchecks.io or UptimeRobot to get built in alerting and retries. The heartbeats are pings to that service.
Watchdog workflow in n8n: runs on a Cron schedule, checks the last heartbeat, alerts on misses, and if allowed, calls a companion webhook on the original workflow to force a restart.

Step by step fix

Open the polling workflow that stops and add a final short branch that always runs after your main processing. Add a HTTP Request node to ping your health monitor. Set Method to GET or POST and the URL to your healthchecks ping URL.
Create a companion Webhook node in the same workflow. Set HTTP Method to GET, give it a path like /watchdog/restart-my-poller. Connect that webhook to the same downstream nodes the polling trigger uses, or to a small wrapper that calls Execute Workflow if you prefer isolation.
Build the watchdog workflow. Use a Cron node set to run every 5 minutes. After the Cron node, check the external monitor or a datastore. If you use Healthchecks.io, you can call its API or rely on the monitor to send alerts. If you used Google Sheets or a DB, use the corresponding n8n node to read the last timestamp.
If the last heartbeat is older than your threshold, send alerts then call the polling workflow companion webhook. Use HTTP Request node to call the webhook URL. Example simple check in a Code node (pseudo):

// inside a Code node after fetching last timestamp
const last = new Date(items[0].json.lastHeartbeat);
const diffMinutes = (Date.now() - last.getTime()) / 60000;
if (diffMinutes > 10) {
  return [{ json: { restart: true }}];
}
return [{ json: { restart: false }}];

Then conditionally use an HTTP Request node to call your companion webhook when restart is true. Also send a message with SMTP, Telegram or HTTP Request to your alerting channel.

n8n tool notes and a sample n8n JSON snippet

Use these specific n8n nodes: Cron for the watchdog schedule, HTTP Request to ping monitors and to call the companion webhook, Webhook to receive watchdog-triggered restarts, and Code to compute age of the last heartbeat. Do not use the old Function nodes, use the Code node for custom JS logic.

Minimal example n8n workflow JSON fragment for the heartbeat + companion webhook. Replace URLs and paths before importing:

{
  "name": "poller-heartbeat-and-webhook",
  "nodes": [
    { "name": "My Polling Trigger", "type": "n8n-nodes-base.trigger", "parameters": { /* your polling node settings */ } },
    { "name": "Health Ping", "type": "n8n-nodes-base.httpRequest", "parameters": { "url": "https://hc.example/ping/PUT-YOUR-CODE", "method": "GET" } },
    { "name": "Companion Webhook", "type": "n8n-nodes-base.webhook", "parameters": { "httpMethod": "GET", "path": "watchdog/restart-my-poller" } }
  ],
  "connections": { /* connect trigger and webhook to your processing nodes, and attach Health Ping at the end */ }
}

This JSON is illustrative. The key idea is the Health Ping node runs on every successful poll, and Companion Webhook lets the watchdog force the same processing path.

How to stop it happening again and reduce false alarms

Make your heartbeat unconditional. Use a separate branch after your main logic so errors inside processing do not prevent the ping. Use the Continue On Fail setting on nodes that may error.
Set sensible thresholds. If your poll interval is 1 minute, consider a 5 to 10 minute alarm threshold to avoid transient network noise.
Monitor upstream limits. If an API rate limit is the root cause, add exponential backoff or reduce the poll frequency. Log error messages in a store so you can inspect them.
Host resilience. If you self host, use Docker restart policies, systemd or PM2 so the n8n service restarts on host failure. That does not replace the heartbeat but avoids downtime when the host dies.

Tool specific notes for Make.com and Zapier

Make.com and Zapier users should also send heartbeats. In Make.com create a scenario step at the end that calls a healthcheck URL. In Zapier add an action to call a webhook or post a timestamp to a Google Sheet. The watchdog can live in n8n or in a simple script that checks the sheet or monitor. The pattern is the same: emit, watch, alert, restart or re-run.

When to get help

If you still see silent stops after adding heartbeats and watchdogs, collect these items before asking for help: the last heartbeat timestamp, the poll interval, the workflow JSON, and any node-level errors. Share them in the n8n community thread, and link to threads like How do you catch a polling trigger that just stops and the free alerting workflow example at Get alerted on failed runs and on workflows that stop running for ideas you can adapt.

Finally, if your workflow must be highly available, combine the heartbeat/watchdog pattern with an external monitor, and keep a manual override webhook so an operator can re-run processing while you investigate.

Learn to build automations like this with Automate Naija.

Frequently asked questions

How can I detect an n8n polling trigger not working without logs?

Add a heartbeat ping to the polling workflow that posts a timestamp to an external monitor or datastore on every successful execution. A separate watchdog workflow polls that timestamp and flags when it is older than your threshold, which detects a stopped workflow even if there are no explicit logs.

Can I automatically restart a stopped n8n workflow?

Yes, use a companion webhook inside the polling workflow. The watchdog calls that webhook to force the same processing path. This avoids needing internal n8n admin APIs and works across self hosted or cloud deployments.

What nodes should I use in n8n for this pattern?

Use Cron for watchdog schedules, HTTP Request to ping monitors and call webhooks, Webhook to receive watchdog restarts, and Code for small timestamp logic. Use Continue On Fail for heartbeat nodes so failures do not stop pinging.

Will external monitors like Healthchecks fix the root cause?

External monitors do not fix root causes, but they alert you early and provide retries. Use them with the watchdog to automate recovery, while you investigate the underlying problem such as API rate limits, credential expiry or host instability.

Build it with us. The community is free and the build track teaches this kind of automation week by week: see pricing or join the community.