How to Monitor n8n Scheduled Workflows

Why n8n Scheduled Workflows Fail Without Warning

n8n's Schedule Trigger node registers itself in memory when the workflow is activated. This architecture means the trigger is only as reliable as the process that holds it. Unlike a database-backed job queue that survives restarts, the schedule state can be lost or corrupted whenever the n8n instance or its workers cycle. Community reports and GitHub issues going back to at least 2024 document workflows that ran correctly for hours or days and then silently stopped, with no error in the execution log and no notification sent. The n8n error-workflow feature only fires when an execution starts and then fails; it cannot catch the case where the execution never starts at all. Layered on top of this are several node-level pitfalls: enabling Continue On Fail on any node in the chain causes n8n to mark the run as successful even when that node returned a 500, a 401, or an empty response, so the execution log shows green while the actual work was never done. In queue mode (the recommended scaling setup for self-hosted n8n), if all worker processes are offline or saturated, executions pile up in a Queued status indefinitely and trigger zero alerts. Finally, n8n's default execution pruning deletes run history after 14 days or 10,000 records, so a pattern of missed runs can disappear from the log before anyone investigates.

• !Instance restart or container redeploy clears in-memory trigger registration, and the workflow must be deactivated and reactivated to re-register, a step that is easy to forget.
• !A workflow toggled to Inactive by any team member, an API call, or an n8n version migration stops all scheduled executions immediately with no notification to other users.
• !Continue On Fail enabled on any node causes the execution to be logged as successful even when that node threw an error, masking failures in HTTP calls, database writes, or file operations.
• !In queue mode, if the worker process crashes or loses its Redis connection, every scheduled execution stays in Queued forever with no alert and no timeout by default.
• !Timezone misconfiguration between the workflow setting and the host system clock causes triggers to fire at the wrong time or not at all, and n8n logs show only that the trigger did not fire, not why.
• !Execution history pruning (default: 14 days or 10,000 records) can delete evidence of a run gap before an operator notices the problem, making post-incident debugging impossible.

The Heartbeat Approach: Monitoring from the Outside In

The only reliable way to catch a scheduled workflow that never starts is to monitor from outside the n8n instance. A heartbeat monitor, also called a dead-man's switch, inverts the usual alerting model: instead of watching for an error event, it watches for the absence of an expected success signal. You configure CronJobPro with the schedule your workflow runs on and a grace window. CronJobPro gives you a unique ping URL in the form https://cronjobpro.com/ping/<token>. You add an HTTP Request node at the very end of your n8n workflow that calls this URL on every successful completion. If CronJobPro does not receive a ping within the expected period plus the grace window, it fires an alert to your chosen channel: email, Slack, Discord, Microsoft Teams, PagerDuty, Opsgenie, or a custom webhook. This approach catches every failure mode that internal n8n tooling misses. It does not care whether the execution never started because the trigger lost its registration, whether the workflow was deactivated, whether a node silently failed under Continue On Fail, or whether the worker queue froze. If your workflow did not complete successfully and call the URL, you get alerted. You can also call https://cronjobpro.com/ping/<token>/fail explicitly in an n8n error-workflow to report known failures immediately, and https://cronjobpro.com/ping/<token>/exitcode/<n> to report a numeric exit code for more granular status reporting.

Add a heartbeat to n8n

1. 1

   Create a heartbeat monitor in CronJobPro

   Log in to CronJobPro and create a new Heartbeat monitor. Set the schedule to match your n8n workflow's schedule exactly (for example, every hour or every day at 03:00 UTC). Set the grace period to a value that gives your workflow enough time to complete, typically 5 to 15 minutes for short workflows. CronJobPro will display a unique ping URL in the form https://cronjobpro.com/ping/<token>. Copy this URL.

2. 2

   Open your n8n workflow and add a final HTTP Request node

   In the n8n editor, open the scheduled workflow you want to monitor. Add a new HTTP Request node after the last node in your workflow's success path. Name it something clear like Ping Heartbeat Monitor so its purpose is obvious to anyone editing the workflow later. Make sure it is connected only on the success branch, not inside any error or fallback paths, so it only fires when the real work completes.

3. 3

   Configure the HTTP Request node

   Set the HTTP method to GET. Paste the CronJobPro ping URL (https://cronjobpro.com/ping/<token>) into the URL field. No authentication, headers, or body are required. Optionally enable Continue On Fail on this specific node only so that a transient network hiccup reaching CronJobPro does not cause your business workflow to appear failed, but note that you should handle this consciously and not apply Continue On Fail to the business logic nodes earlier in the chain.

4. 4

   Add a failure path that calls the /fail endpoint

   Create an n8n error workflow (or add an error-trigger branch in the same workflow if your structure permits). In that error path, add a second HTTP Request node that calls https://cronjobpro.com/ping/<token>/fail with method GET. This ensures that if n8n does catch a runtime error, CronJobPro registers an explicit failure immediately rather than waiting for the timeout, which speeds up your alert.

5. 5

   Verify end-to-end by triggering a test run

   Manually execute the workflow once using the Execute Workflow button in the n8n editor. Confirm in the n8n execution log that the HTTP Request node ran and returned a 200 status. Then check CronJobPro to confirm the ping was received and the monitor shows a healthy last-ping timestamp. Temporarily set the workflow schedule to every minute, wait two cycles, and confirm two pings appear in CronJobPro before restoring the real schedule.

{
  "name": "Ping Heartbeat Monitor",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 4,
  "position": [1200, 300],
  "parameters": {
    "method": "GET",
    "url": "https://cronjobpro.com/ping/YOUR_TOKEN_HERE",
    "options": {
      "timeout": 10000,
      "response": {
        "response": {
          "neverError": true
        }
      }
    }
  }
}

Frequently asked questions

More monitoring guides