When connecting monitoring to anything else, you choose a direction. Either the source pushes events to you, or you pull them on a schedule. The choice determines your latency, your failure modes and how much infrastructure you need.
Webhooks: the source pushes
An event happens, the source immediately sends an HTTP request to a URL you provide. Latency is near zero. Nothing happens when nothing happens. But you must run an endpoint: publicly reachable, always up, fast enough not to time out. That last point is where the real cost sits — your webhook receiver is now production infrastructure that needs to be up precisely when things are going wrong.
Polling: you pull
On a schedule, you call the source's API and ask what changed. It is simple: a script and a cron entry, no inbound network exposure. It is robust to your own downtime — if your poller is down for an hour, it catches up. But latency equals your interval, and most polls return nothing.
The retry question decides more than anything else
The most important practical difference is what happens when delivery fails. Many webhook senders do not retry. A single attempt, and if your endpoint is slow or briefly down, the event is gone. This is dangerous for alerting, because your receiver is most likely to be struggling during exactly the incidents you most need to hear about.
Check this before you rely on it. If your source does not retry, design around it: keep your receiver trivially fast (accept, persist, return 200, do the work asynchronously), add a low-frequency reconciliation poll as a safety net, and monitor the receiver itself.
Timeouts are tighter than you expect
Webhook senders typically allow a few seconds before giving up. Five seconds is common. If your receiver authenticates, queries a database, calls a downstream API and formats a message, you can exceed it under load — and under load is exactly when incidents happen. Do the minimum synchronously: parse, validate, persist, respond.
Security considerations differ
Webhooks need you to verify the sender; anyone who learns your URL can post to it. Treat webhook URLs as credentials. Polling avoids this entirely — you initiate the connection and authenticate normally, with no inbound firewall exposure.
Ordering and idempotency
Webhooks arrive in whatever order the network delivers them, and retries can produce duplicates. Your receiver must be idempotent: key on the event's identifier and make processing the same event twice harmless.
Choosing
Use webhooks when latency matters, the sender retries, and you can run a reliable endpoint. Use polling when you cannot expose an endpoint, the sender does not retry, or minutes of latency are fine. Use both when it matters: webhooks for speed, a periodic reconciliation poll for completeness. It is more code, and for anything where a missed alert is a real problem, it is the right answer.