Where push architectures break

Provider reliability is not your reliability

The first thing you learn about webhooks in production is that you are outsourcing your availability to every provider you integrate with. When Notion has a bad hour, you don't get those events. They don't retry. They don't queue. They don't even tell you they failed. You have an IP allowlist and a prayer.

GitHub gives you three delivery attempts. If all three fail because your endpoint was down for five minutes during a deploy, those events are gone. You can check the webhook delivery log in Settings, see the failures, and manually redeliver them one by one. For ten events, that's annoying. For two hundred, you're writing a script.

Linear retries for two hours, which sounds generous until a partial outage on their end generates a burst of retries alongside the normal event flow. Now you're handling the real events and the ghosts at the same time, and your deduplication layer had better be solid.

Jira doesn't retry at all. If you missed it, you missed it.

The counterpoint is that polling would have caught all of these. A poll runs on your schedule, against the current state, and picks up whatever is there. If the provider was down for an hour, you get the resulting state on the next sweep. You don't get the intermediate transitions, but you get the outcome.

Ordering, replays, and thundering herds

Webhooks arrive in whatever order the provider sends them. An "issue closed" event can land before the "issue created" event if the provider's internal pipeline batches them differently or routes them through separate queues. Your agent receives a close event for an entity it has never seen. What does it do?

The careful answer is: buffer it, wait for the creation event, then process both in order. The real answer, for most teams, is: crash, log a confusing error, and move on. You find out weeks later when someone asks why a ticket was never tracked.

Out-of-order delivery means your agent needs a local model of entity state that can handle gaps, a reconciliation pass that fills them, and enough retained context to decide whether a gap matters. This is real engineering work, and it compounds across providers.

Replay storms

Worse than missing events is getting all of them at once. A provider has an incident, recovers, and replays twelve hours of queued webhooks in a burst. Your queue depth goes from 3 to 4,000 in under a minute. Your worker auto-scales, maybe, if you configured that. But the worker takes a Redis lock per entity to prevent concurrent processing of the same ticket, and now four hundred workers are contending on twenty locks. Throughput drops. Latency spikes. Your monitoring fires every alert you have.

This pattern is well-documented in production webhook systems. The standard mitigations are partitioned locks (by entity type rather than global), increased lock granularity, and autoscaling rules that can handle burst multiples of steady-state load. But most teams don't invest in these until they've lived through a replay, because steady-state operation never exercises the burst path.

Thundering herds

Even without a provider incident, bulk operations generate the same spike pattern. Someone imports 300 tickets from a CSV. A project manager moves 50 issues between boards. An admin changes a field across an entire workspace. Each of those individual changes fires a webhook. Your agent, which handles 10 events per minute comfortably, now has 300 in the queue.

You need backpressure. You need rate limiting on the consumer side, not just the producer side. You need graceful degradation: the ability to process the burst slowly rather than falling over entirely. Most webhook tutorials don't mention any of this, because most webhook tutorials stop at "receive event, log body, return 200."

Schema drift

Providers change their webhook payloads. Sometimes they add fields. Sometimes they rename them. Sometimes they change the shape of a nested object. They give you ninety days notice if you're lucky. Stripe is good about this and pins payloads to your API version. Most providers are not Stripe.

With polling, schema drift is painful but visible. You call the API, you get back the new schema, your parser breaks loudly, you fix it. The current API version is the only version you ever see.

With webhooks, schema drift is silent. Your parser was written against the old schema. The new payload arrives, the changed field parses to null or falls into a catch-all, your agent acts on incomplete data, and nobody notices until a user reports something wrong. The failure doesn't look like an error. It looks like slightly wrong data, for days, until someone notices.

The mitigation is a schema regression test per provider: store a sample payload, run the parser against it on every CI build, and fail loudly when the shape changes. Simple to build, but most teams don't think to build it until after the first silent break.

When polling is genuinely better

There are cases where push is the wrong tool, and recognizing them saves you from building complexity you don't need.

Batch digests. If your agent produces a Monday-morning summary of last week's activity, it doesn't need real-time events. It needs a single sweep of the relevant APIs, once, at 7 AM. A cron job and a well-structured API call will outperform an event-driven pipeline that accumulates, deduplicates, and aggregates a week of webhooks.

Long compute without freshness requirements. An agent that analyzes a codebase for security patterns, generates a report, and emails it to the team doesn't benefit from sub-second event delivery. It benefits from a clean snapshot of the current state, taken at a predictable time. Polling gives you that snapshot naturally.

Providers with limited or complex push support. HubSpot private integrations don't get webhooks. Some internal tools expose REST APIs but nothing event-driven. Even providers that do offer push (like Google Drive's push notifications) sometimes require enough setup (channel registration, renewal, verification) that polling is simpler for low-volume use cases. For these providers, polling is a reasonable default, and wrapping a poll in an event-shaped abstraction just adds indirection without adding value.

Early prototyping. When you're trying to figure out whether an agent idea works at all, the last thing you want is to build webhook infrastructure. Poll the API, process the results, see if the agent's behavior makes sense. You can add push later, once you know the idea is worth the engineering investment.