n8n Monitoring6 min read

How to Monitor n8n Webhooks and Catch Missed Triggers

Webhook-triggered workflows are great until the webhook stops being called. Maybe the external service changed its payload format. Maybe it stopped sending events entirely. Maybe your n8n instance was down for 30 seconds and missed the POST request — and unlike a cron trigger, webhooks don't retry by default.

Monitoring webhook-driven workflows has a unique challenge: you can't predict when they should fire, so detecting "missed" triggers is harder than detecting missed cron executions.

The webhook reliability problem

Cron-triggered workflows are predictable. If a workflow runs every hour, you know to expect 24 executions per day. Webhook-triggered workflows are event-driven — they fire when something happens externally. This makes it harder to set a baseline for "this should have run by now."

Common failure modes: the external service silently stops sending webhooks (API changes, misconfiguration on their end), n8n misses the webhook because it was restarting, or the webhook payload changed and your workflow's first node errors out before meaningful processing begins.

Three webhook failure modes: source stops sending, n8n misses the POST, payload changedSource stops sendingAPI changeConfig issue on senderNo execution logged★ Needs external detectionn8n misses the POSTInstance restartingNetwork blip / timeoutNo execution logged★ Needs external detectionPayload changedFirst node errorsRest of workflow skippedError logged (catchable)Error Trigger works
Two out of three webhook failure modes produce no error log at all

How to monitor webhook workflows

For execution errors (payload changes, node failures), n8n's Error Trigger works. The webhook fired, the execution started, something broke — that's a normal error you can route to Slack or email.

For the other two — source stops sending or n8n misses the POST — you need a tool that notices the absence. RootBrief tracks execution frequency for all your workflows. If a webhook-triggered workflow that usually fires 50 times a day suddenly drops to zero, RootBrief flags the anomaly. It can't tell you why the external service stopped sending events, but it can tell you that they stopped — which is the critical first alert.

Practical advice

For high-value webhook workflows, also add a "heartbeat" check: have the external service send a test webhook every hour (if possible), so you have a predictable baseline to monitor against. Pair that with RootBrief's execution monitoring and you'll catch both gradual degradation and sudden stops.

Complete webhook coverage: Error Trigger for payload errors plus RootBrief for silent absenceError TriggerCatches payload errorsKnown failures+RootBriefCatches silenceUnknown absences
Use both: Error Trigger for known failures, RootBrief for unknown absences

Webhooks don't retry. RootBrief notices when they stop arriving — try it free — no credit card required.

Monitor your n8n workflows in 2 minutes

RootBrief detects failures, explains root causes in plain English, and alerts your team via email or Slack.

Start free