Your automation succeeded. Your webhook never fired. And you won't know until a user calls to complain.
This isn't an edge case. It's a gap in how most teams monitor automations — and it exists because the two ways we watch automations work directly against each other.
The Two Ways You See Automations
When you want to know what your n8n workflow or Make scenario actually did, you have two choices:
Webhooks (push). Your workflow finishes, it POSTs run telemetry to an endpoint you control. This happens seconds after the run completes — nearly instant feedback. You own the data path end-to-end.
API polling (pull). You periodically query the platform's API — "Give me the last 100 runs on this workflow" — and ingest whatever you get back. This is continuous observation, but it's delayed and dependent on the platform's API accuracy.
Most monitoring stacks use one or the other. Some use both. And almost every team that uses both discovers, eventually, that they disagree on whether a run happened.
Why Webhooks Are Fast but Fragile
A webhook is fire-and-forget. Your automation ends → it POSTs JSON to your endpoint → your endpoint returns 200 OK → the platform considers its job done.
This works beautifully when everything is connected and both systems are responsive. But:
- Your endpoint is down. The platform fires the webhook, gets a timeout or 5xx, and... what then? If it retries, how many times? If it doesn't, that run is permanently invisible to you. Different platforms handle this differently — some retry indefinitely, some give up after a few attempts, some don't retry at all.
- Network blip. The request leaves the platform's data center, crosses the internet, and never arrives. No error on either end. The platform has no way to know it never landed.
- Your endpoint received it, but silently failed. Your webhook handler crashed, threw an exception that you caught but didn't log, or wrote to a database that's now unavailable. The platform got a 200 OK (because your load balancer accepted the connection) and moved on. The webhook payload is lost.
The contract of a webhook is delivery, not durability. For most low-stakes data it's fine. For mission-critical runs, it's a gamble.
Why API Polling Is Reliable but Slow
You ask the platform "what happened?" periodically — every 3 minutes, every 10 minutes, whatever interval you choose. This has real advantages:
- Eventual consistency. Even if you miss a webhook, the next poll asks the API and gets the truth (or at least, the platform's truth).
- Batch retrieval. One API call can give you 100 runs at once, so you're not individually tracking every execution.
- Auditability. If a run is missing from your records, you can ask the platform again and get it.
But:
- Latency. If a critical workflow fails at 2:00:47 PM and you poll every 3 minutes, you might not know until 2:03 or 2:04. On a real outage, those 180 seconds can matter.
- Platform API accuracy. The API itself can lag. Make sometimes takes 30 seconds to reflect a run in its API even after the run completes. n8n's API can miss runs if you hit rate limits. Some platforms don't expose failed runs in their API at all, only through the UI.
- Incomplete history. If you poll every 3 minutes but the platform only retains run history for 30 days, and you miss a poll window, that data is gone forever.
The polling contract is "I'll tell you what I know, when you ask" — not "I guarantee you'll see every run."
The Real Gap: What Happens When They Disagree
You set up both webhooks and polling on the same workflow. This is smart — webhook for speed, polling for insurance. Then one morning you notice:
- Webhooks show 47 runs in the last 24 hours.
- Polling shows 51 runs.
Which one is right?
Usually, polling is closer to truth, because the platform's own database is the source of record. But "closer" isn't certainty. The platform might have runs it doesn't expose in the API. The API might be showing runs that were later rolled back or soft-deleted. Your webhook handler might have silently failed to write to the database, so polling retrieved data that never made it to your monitoring system.
Now you have two data streams and neither is canonical.
A few concrete scenarios this creates:
- Stale alert. Polling sees a run failed 4 minutes ago. Webhooks saw it 30 seconds ago and already alerted your team. Now your polling refresh fires the same alert again. Did you dedup, or does the team get woken up twice?
- Missing run. A webhook-push workflow has no polling configured (to save API costs). One day the webhook endpoint goes down for 90 seconds. A run happens during that window and POSTs to a dead endpoint. No retry happens. Polling never started. The run is permanently invisible.
- False recovery. Polling shows a workflow recovered (a successful run after several failures). Webhooks never reported that success (the endpoint was unreachable, but the platform gave up retrying). You celebrate the recovery, but the underlying issue never fixed itself — you just lost visibility.
What Actually Reliable Monitoring Does
If you're building a system that needs to reliably see automation runs, you have to account for both gap types:
Assume webhooks will fail. Treat them as the first signal, not the only signal. If a webhook lands, act on it immediately (speed matters). But don't trust it alone for anything you can't afford to miss.
Assume polling will lag. Use it as your source of truth for reconciliation. Poll at an interval tighter than you'd be willing to miss (3 minutes is typical for most workflows; 10+ minutes is risky if you care about MTTR). But don't expect it to be faster than your webhook for fresh events.
Use both to cross-check. When polling results contradict recent webhooks, you have a signal: something went wrong on the delivery path. That's when you investigate why a webhook failed, why the API is stale, or why your handler crashed.
This is why OpsVeritas supports both webhook ingest and (for API-backed platforms like n8n and Make) simultaneous polling. They converge on the same workflow — the system sees both data paths, treats webhooks as the initial signal, and uses polling to catch what webhooks miss. When both agree, you have confidence. When they disagree, it's a clue.
The Implication
If you're monitoring automations today with just webhooks or just polling, you're leaving a gap. Webhooks alone means you're betting your visibility on network reliability and endpoint uptime — both things outside your control. Polling alone means you're betting on acceptable latency and API accuracy — also outside your control.
The only way to be sure is to see runs through multiple paths and reconcile them. It's more complex than a single-path solution. It's also the only architecture that catches the silent failures that neither webhooks nor polling alone can guarantee.
The question isn't which method to use. It's whether you're willing to see what you're actually missing.
Top comments (0)