Your Endpoint Was Down. Which Webhooks Are Gone?

What a webhook outage costs you is decided by the source with the shortest retry window, not the longest. Stripe keeps trying for three days. Slack gives up about five minutes in. Shopify stops after roughly four hours and then removes the subscription, so when your server comes back you are not behind, you are unsubscribed. Retries are not a recovery plan, they are a grace period of wildly different lengths, and the actual recovery is a reconciliation sweep that only works for some kinds of events.

How long each source actually keeps trying

Here is what the four most commonly integrated sources document, checked in September 2026.

Source	Retries after failure	Total retry window	Response deadline	If you are still down at the end
Stripe	Exponential backoff	Up to 3 days, live mode	Return 2xx before heavy work	Events remain listable for 30 days
Shopify	Up to 8	About 4 hours	5 seconds	Subscription removed after repeated failures in 24 hours
HubSpot	Up to 10	24 hours	Not published	Stops, and never retries a 4xx at all
Slack	3 (immediate, 1 min, 5 min)	About 5 minutes	3 seconds	Subscription disabled above a 95 percent failure rate in 60 minutes

Two things in that table get missed. The first is the response deadline column, which is a separate failure path from being offline. Shopify requires a response within five seconds and Slack within three. An endpoint that is alive but slow, because it does the CRM write and the Slack post and the PDF render before returning, fails those deadlines under load and burns retries exactly when volume is highest. Returning 200 first and processing afterward is not a performance nicety, it is what keeps you subscribed.

The second is that HubSpot will not retry a 4xx at all. If a bad deploy makes your endpoint return 404 or 403 for an hour, HubSpot treats that as a permanent answer for every notification in that hour. There is no backlog waiting for you.

The failure that produces no errors

Losing a few hours of events is the recoverable version of this problem. The unrecoverable version is that the subscription itself is gone.

Shopify's troubleshooting documentation is explicit: after multiple failures in a 24-hour period the webhook subscription is removed, and you have to recreate it once you have fixed the underlying issue. Slack disables event delivery when SSL failures, timeouts over three seconds, redirect loops, or non-2xx responses account for more than 95 percent of delivery attempts within 60 minutes, with an exemption for apps receiving under 1,000 events per hour.

Read what that means operationally. Your server is healthy. Your logs are clean. Your error rate is zero, because nothing is arriving to fail. Every monitor that watches for failures sees a perfect system, and the only signal available is absence, which nothing alerts on by default. This is the single most common way an integration dies quietly, and it is why the alert that matters is a staleness alert on each topic, not an error-rate alert. If the orders topic normally fires 40 times a day and has fired zero times since 2 a.m., that is the page.

After any outage longer than a few minutes, the first thing to check is not the backlog. It is whether the subscriptions still exist.

Which missed events can you rebuild, and which are gone

Sort every webhook topic you consume into two buckets. This classification decides your entire recovery, and almost nobody does it before they need it.

State-derivable events. Order created, contact updated, invoice paid, deal stage changed. The fact the event carried is still sitting in the record. You can list every record modified during the outage window, sorted and filtered by the source's modified timestamp, paginate through it, and run your normal logic. Recovery is a query.

Event-only facts. An inbound message, a form submission that was not persisted anywhere else, a card that declined and then succeeded on retry, a status that flipped and flipped back, a hard delete. The current state of the record does not contain these. Reading the record tells you nothing happened, and you cannot distinguish a customer who never replied from one whose reply you dropped.

For the second bucket there are exactly two outcomes: the vendor keeps an event log you can replay from, or the data is gone. Stripe keeps one, and it is worth knowing the exact call. You can list events from the last 30 days and filter to delivery_success=false to get only the events that failed to reach at least one endpoint, then auto-paginate with ending_before set to the last event you know you processed, which returns them in chronological order. That is the difference between a 20-minute recovery and an apology to a customer.

So do the inventory now, while nothing is broken. One row per webhook topic, three columns: is it state-derivable, does the source expose a filterable modified timestamp, and if it is event-only, is there an event log. The rows with no in the last two columns are your real exposure, and they are the ones worth engineering around, either by writing every raw payload to storage on arrival or by not depending on that event for anything that matters.

There is a related trap here for deletions specifically, which is that a delete event has no state to fall back on by definition. That is one of several reasons to write a deleted flag instead of removing the row.

What your automation platform does while you are down

Where the workflow runs changes the exposure, and the differences are larger than the marketing suggests.

Make queues incoming webhook data in the webhook's own queue regardless of whether the scenario is active, which makes it the most forgiving of the three. The queue is not unlimited: Make's documentation caps it at 667 items per 10,000 credits licensed per month, with a hard ceiling of 10,000 items per webhook. A paused scenario on a low-volume topic is fine for days. A busy topic can fill the queue and start losing data while the scenario sits off.

Zapier's autoreplay covers a different case than most people think. It replays Zap runs that started and errored, up to five attempts, with the last one landing about 10 hours and 35 minutes after the first error, and it requires a Professional plan or above. Manual replay is available within 60 days of the trigger event. All of that applies to runs that exist. A delivery that never arrived produces no run and therefore nothing to replay.

Self-hosted n8n is the most exposed. If the container is down or the reverse proxy is misrouting, the source's HTTP request fails outright, and the source's retry window is your entire safety net. For a Shopify topic that is four hours before the subscription starts getting removed. Anyone running a self-hosted runner for revenue-carrying webhooks should either put a durable queue in front of it or accept that their maximum tolerable downtime is measured in hours, not days. Which of those you pick is an architecture decision worth making deliberately rather than discovering during an incident.

The recovery, in order

1. Restore the endpoint, then verify the subscriptions. List your registered webhooks at each source and compare against what you expect. Recreate anything Shopify removed or Slack disabled before you touch the data, otherwise you will backfill history perfectly and then go quiet again.
2. Pin the window. Take the timestamp of the last event you know you processed, not the time the alert fired, and extend the end of the window past your recovery time by at least the source's retry window so you do not double-handle deliveries still in flight.
3. Replay from an event log where one exists, sweep by modified timestamp where it does not. Stripe gets the failed-delivery event list. Shopify and HubSpot get a paginated query on records modified inside the window. Slack gets whatever you can reconstruct from channel history, which is the message text but not the trigger.
4. Make every write idempotent before you run any of it. Key on the source's event ID or record ID, check before insert, and guard updates with a per-record watermark so a replayed event cannot overwrite something written after the outage. A sweep without this is how a four-hour outage becomes a week of deduplicating records by hand.

Then write down what you could not recover, with counts. Not for a postmortem document nobody reads, but because that list is the specification for the next thing you build.

Make the next one boring

The work that pays here is cheap and unglamorous. Return 200 within the deadline and do the real processing asynchronously, which keeps subscriptions alive through load spikes as well as outages. Log the delivery ID and event ID of everything that arrives, because a recovery sweep is only as precise as your record of what you already handled. Set a staleness alert per topic with a threshold based on that topic's normal quiet hours, not a global one.

Best of all, build the reconciliation sweep before the outage and schedule it nightly. A job that re-checks the last 24 hours of modified records against what you have is a working backup that proves itself every day, and it turns most outages into a non-event you find out about from a log line rather than a customer. If you want a second opinion on which of your integrations would survive a four-hour outage and which would not, tell us what you are running and we will map the retry windows against your topics.