Orders stopped arriving, and the other end stopped calling

September 5, 202618 min readUpdated September 13, 2026

Orders stopped syncing into the spreadsheet some time last week, and nobody can say when. The fulfilment sheet has a hole in it, the accounting system is short a dozen invoices, and nothing on your side reported a thing. The webhook stopped working in the only way one can: the other platform stopped sending. A webhook is that other system pushing you an event the moment it happens, a new order or a payment, instead of waiting to be asked.

There is no failed run to open, because nothing arrived to start one. Your software spent the week doing what it does on a quiet Sunday.

So orders stopped syncing here for a different reason than an automation that ran, reported success and did nothing useful, which has its own piece: why automations fail silently. Here the job is to work out that a conversation ended, when it ended, and what fell into the gap.

Four platforms, four different answers to what happens after enough failed deliveries, all taken from their own documentation and read in August 2026. These numbers move. Check the vendor's page rather than this one.

Why do orders stop syncing when a webhook stops working?

Because the platform on the other end gives up, and giving up is silent. Three of the four platforms below eventually stop the subscription, which is the standing instruction to send you those messages and not a thing you pay for. Nothing is held for you in the meantime.

Where deliveries go straight to a web address over HTTPS, the ordinary setup, Shopify stops after eight failed attempts in four hours, and Square after three weeks without one successful delivery. WooCommerce stops after five failures, or more than five, depending which of its two official pages you read.

Shopify states the mechanism at the bottom of a page about delivery over HTTPS. The same page opens by noting that cloud event buses such as Google Pub/Sub and Amazon EventBridge "handle these concerns for you". A shop wired up that way is reading about somebody else's problem. For everybody else: "If Shopify receives no response or an error, it retries 8 times over the next 4 hours. After 8 consecutive failures, the subscription is automatically deleted if it was configured using the Admin API. Warning emails are sent to the app's emergency developer email address."

The middle sentence is the one that decides whether this happens to you at all. Shopify documents two ways a subscription exists. App-specific ones, declared in an app's own configuration file, are Shopify's recommended default, and for those "Failing subscriptions will not be deleted by Shopify". Shop-specific ones are created through the Admin API, the programmer's door into your shop that an app uses instead of the screens you see. Those are the ones that get deleted. You will not know which kind your app used without asking the developer, and that is the question worth asking.

Shopify's troubleshooting page adds the detail that sets the pace: "Each time a delivery fails, the interval before the next retry increases. This can cause your data to become out of sync, especially if you process many events or time-sensitive data."

So the window can close inside an afternoon. Your endpoint, the address on your side that answers when Shopify calls, being down over lunch and a server gone for a month end up in the same place.

Those numbers changed in September 2024, when Shopify announced that "Webhooks will now be retried a total of 8 times over 4 hours using an exponential backoff schedule." Forum answers older than that describe a different system.

The vendor's own page is not consistent either. It opens with retries "up to eight times in a four-hour period", while its metrics table says "After multiple failures in a 24-hour period, the webhook subscription is removed". Four hours is the retry window, corroborated on two other Shopify pages, and the twenty-four-hour figure is where most second-hand accounts of this come from.

What do Shopify, Stripe, Square and WooCommerce do after failed deliveries?

They diverge more than you would expect for four systems doing one job. Shopify deletes the subscription. Square discards the notification after twenty-four hours, and separately disables the subscription after three weeks without a single success. WooCommerce sets the webhook to a status of Disabled. Stripe is the only one that will re-send events to your address on request. Square keeps them too, but somebody has to go and pull them.

	How many retries	Over what period	What happens after	Can missed events be recovered	Does anybody tell you
Shopify	8	4 hours, exponential backoff	Subscription deleted for shop-specific subscriptions created through the Admin API; app-specific subscriptions declared in the app config are not deleted; removed subscriptions "won't receive any deliveries unless you create them again"	No replay. Re-create the subscription, then query the Admin API for the records in the gap and feed them in yourself	Yes. Warning emails to the app's emergency developer email; for app-created webhooks, also to the store owner
Stripe	Not published as a count	Up to 3 days, exponential backoff in live mode; 3 attempts over a few hours in a sandbox	Retries stop. No automatic disabling for delivery failure is documented; the disable-reason list covers a missing AWS source, a missing Azure topic, and `user`	Yes. Resend from the Dashboard for 15 days, `stripe events resend` for 30; list events with `delivery_success=false`, 30-day retention	Not documented. No Stripe page read here says a failure email is sent
Square	11, on a published schedule from 1 minute to 24 hours	24 hours	Notification "is discarded and no further retry attempts are made". Subscription disabled if no single 2xx arrives in three weeks	Yes. Events API, 28-day window, called by Square "a disaster recovery and reconciliation mechanism for missed webhook events"	Yes. Warning emails after week one, week two and week three, then disabling
WooCommerce	No retry policy published	n/a	Status set to Disabled. woocommerce.com says "after more than five consecutive delivery failures"; the REST API docs say "After 5 consecutive failed deliveries"	No documented mechanism. No replay and no event archive	Only on screen: the status reads Disabled, and deliveries are logged under WooCommerce > Status > Logs

Read the recovery column first, because it decides what your week looks like. On Stripe the events are still there. On Square you have twenty-eight days to pull them. On Shopify you fetch the orders through the Admin API yourself. On WooCommerce there is nothing published to recover from.

The gentlest rule is Square's. Its three-week clock runs on the absence of a single successful delivery, so one good response resets it. Shopify's eight failures are consecutive and counted in hours.

One row in that table needs its caveat said out loud, because plenty of third-party writing gets it wrong. The claim is that Stripe disables an endpoint that keeps failing, and no Stripe page read here says so. Stripe documents three reasons a destination can end up disabled, and continued failure is absent from that list. That is evidence about the documentation rather than about the behaviour.

The WooCommerce row is an absence too. Neither official page describes any retry of a failed delivery, or any way to replay one. WooCommerce does not publish a retry policy.

If you would rather have somebody go through the connections you depend on and put a number against each one, that is the process audit. $299, three business days, and a written map you keep whether or not you hire us.

What counts as a failure, and who decides?

The sending platform decides, and its definition is narrower than yours. Shopify treats anything outside the 200 range as an error, redirects included, and allows five seconds for the whole request. Those 200s, also written 2xx, are the codes a server sends back to mean "received". Square wants a 2xx as soon as possible. WooCommerce's two official pages disagree with each other about whether a redirect counts at all.

	Counts as success	Response deadline
Shopify	200-series only; "Any response outside the 200 range, including 3XX codes, is treated as an error"	1-second connection timeout, 5 seconds for the whole request
Stripe	2xx; redirects fail, "We consider redirect responses to webhook requests as failures"	Not published as a number; "quickly return a successful status code (`2xx`)"
Square	2xx	"as soon as possible"; a duplicate is sent and "your application has 10 seconds to respond"
WooCommerce	Per woocommerce.com: 2xx, 301 and 302. Per the REST API docs: 2xx only	Not published

That last row matters more than it looks. An endpoint that answers with a redirect and then a 200 has, from the receiving end's point of view, worked perfectly: the payload arrived and was processed. A sender that counts the redirect as a failure disables the webhook anyway. Everything worked, and the connection was switched off regardless, which is why the two WooCommerce pages disagreeing about 301 and 302 is not a detail.

One thing the deadlines do not mean. Each one measures how fast your endpoint says it received the message, and the work behind it can take all afternoon. Shopify's advice is to "delay processing until after you've sent a response".

Deleted or disabled: which one are you fixing?

The difference decides how long the repair takes and who can do it. A disabled webhook still exists in the admin, with a status saying so, and somebody with a login switches it back on. A deleted subscription is gone, and has to be created again through the API by whoever holds the access.

WooCommerce is the friendly case. Its status field is documented as "Active to deliver notifications, Paused to stop delivery temporarily, or Disabled to stop delivery due to failures". The record sits in the admin, doing nothing, until somebody changes it.

Shopify is the awkward one, because there is nothing left in the admin to switch back on. Its guidance on recovering from downtime says where to look: "For shop-specific webhook subscriptions, consult the app's code that initially created the subscriptions."

Consult the app's code. On the morning an owner finds the gap, that means locating whoever set the connection up, and the credentials they used. Which is a question about who holds the accounts your automations run on, answered on the day it is most expensive to answer.

Does anybody tell you?

Two of the four send an email, one documents none, and one puts it on a screen you have no reason to open. Shopify emails the app's emergency developer address, and for webhooks created by an app it emails the store owner as well. Square sends three warnings across three weeks. WooCommerce documents no email, only the status in the admin.

The developer address is the interesting one. It belongs to whoever built the integration, which may be an agency you stopped working with in March. Naming who receives the alerts is one item on the handover checklist, and this is what it costs when that item was skipped.

The page a merchant would actually open, Shopify's own Help Center, does tell the owner. Read in August 2026, it says: "You receive an email at the store owner's email address when a webhook fails... If the webhook destination repeatedly returns a non-200 status response, then the webhook subscription is automatically deleted from your Shopify admin."

That page leaves out three things. No retry count, no time window, no word about recovery. It tells an owner the thing was deleted, and never that the orders in between are theirs to collect.

The email itself says that one or more webhooks have been failing and that the subscriptions will be automatically deleted for any deliveries that continue to fail over the next 48 hours. It names the topic that is failing, order fulfilment say, and gives a deadline. What it does not do is reach anybody who can act on it: the store owner who receives it has usually never heard the word webhook, and the developer who would understand it is not on the distribution list. That 48 hours is the email's own deadline, quoted by a merchant, and not a documented figure.

Can you get the missing orders back?

Sometimes, and the window is shorter than the time it takes to notice. Stripe keeps the events and resends them, fifteen days from the Dashboard and thirty from the command line. Square holds twenty-eight days. Shopify holds nothing, so recovery means fetching the orders themselves. WooCommerce documents no mechanism at all.

Stripe also lets you ask which ones you missed, by listing events with delivery_success set to false, which retrieves "events that were unsuccessfully delivered to at least one of your webhook endpoints". The same page carries the limit: "Stripe only returns events created in the last 30 days."

One trap there is easy to walk into. Stripe warns that it "still considers your manually processed events as undelivered and continues to automatically retry them". The same order can arrive twice, once by your hand and once by the retry, and whatever processes it has to survive that.

Square's Events API is the same idea in another shape. Square calls it "a pull-based alternative to webhooks" that "serves as a disaster recovery and reconciliation mechanism for missed webhook events", limited to the past 28 days.

Shopify's recovery is a different operation, and that distinction is the point. The events are not sitting in a queue waiting to be released. In Shopify's words, "you can recover by re-subscribing to your webhook topics (if applicable) and importing the missing data". Importing means fetching the orders from the Admin API for the outage period yourself.

Switching the endpoint off yourself while you fix it digs the same hole deliberately. Stripe is blunt: "Stripe won't attempt to resend any events generated while the destination is disabled." It documents the adjacent case too: "If your destination has been disabled or deleted when we attempt a retry, we prevent future retries of that event."

The safer repair keeps the endpoint answering. Have it accept the message, store the raw payload somewhere dull, and reply with a 2xx while the broken part behind it is fixed. The raw payload is the message exactly as it arrived, before anything has read it. Then replay your own copies once the fix is in.

How long does this run before somebody notices?

Days to a month, and the discovery is nearly always accidental. The developer finds out while chasing something else entirely; the shop notices because a customer rings about an order that never shipped; the bookkeeper notices at month end that a share of the orders paid through the card processor were never marked paid. None of it is caught by an alarm, because nothing was set up to alarm.

Support desks are not always the shortcut either. The vendor's support can truthfully say that nothing changed on their side, because from their side nothing did: the subscription was deleted by the documented rule, and the rule is on a page nobody read.

None of this measures how often the problem happens. Shops whose integrations are fine do not write in.

Does the test button prove anything?

It proves the path was open at the moment you pressed it. It says nothing about whether a real event arrives, or whether the receiving end acts on one. The split shows up regularly: the test event from the platform's console triggers the application and works as intended, and a live event of the same type does not. The platform's logs show successful deliveries for both. Both statements are true at once. The platform sent, the platform recorded a success, and the work the shop cared about did not happen.

The usual cause is a permission. A live event carries data a test event does not, the integration needs a scope such as ORDERS_READ to act on it, and that difference does not show up in a test.

So test with a real transaction, and check the far end of the chain: whether the order reached the sheet.

How do you check this today?

In under an hour, with no tooling, in this order. The first two steps tell you whether orders stopped syncing because a webhook stopped working, or for some other reason. The third is the one people skip and regret, because recovery windows expire while the repair is argued about.

Find the edge of the gap. In the sheet, the accounting system or the fulfilment list, find the last order that arrived on its own. That timestamp starts everything you have to recover.
Ask the sending side whether the subscription still exists. On WooCommerce that is WooCommerce > Settings > Advanced > Webhooks, where a status of Disabled is your answer. On Shopify a deleted subscription is simply not listed any more.
Work out what is still recoverable before you fix anything. Twenty-eight days at Square, thirty at Stripe, your own order history at Shopify. The clock runs from the event, not the discovery.
Search email, including somebody else's. Warnings may have gone to whoever built the integration rather than to you. Ask them to look.
Repair, then backfill, then count. Re-enable or re-create, import the missing period, then compare orders per day on both sides until they agree.
Write down what the vendor's page said and the date you read it. The next person to touch this, including you in a year, will need it.

What stops it happening again?

A second path that pulls, rather than a better endpoint. Shopify recommends it in one sentence: "A common practice is to also build a reconciliation job that periodically retrieves data you might have missed using Shopify APIs." Square offers its Events API in the same spirit. Pushing is fast, pulling is honest, and a small business wants both.

In practice that is a nightly job. It asks the platform how many orders it recorded yesterday, compares that with how many landed in your systems, and raises a person when the two differ. A month of silence becomes one email.

The second is a check that the subscription still exists, run on a schedule rather than only when somebody deploys. A deletion then surfaces within a day.

Both are upkeep, which is the cost line most quotes leave out. It sits beside monitoring and small fixes in what automation costs a small business.

What to ask the person who set this up

Five questions, none of which need technical knowledge, and all of which are cheaper to ask before the connection breaks than after it. The answers tell you whether anybody would find out next time, and how long the repair would take. If it was you and a tutorial who set this up, ask them of the setup itself.

What happens if my endpoint is down for an afternoon? You want the platform named and the number quoted, with the page it came from.
Which address gets the warning email, and who reads that mailbox? If it is a developer address at a company you no longer work with, that is today's job.
If the subscription is deleted, who recreates it, and how long does that take? Ask what access that person needs and whether they still have it.
How would we get the missed orders back, and how long is the window? The answer differs per platform and it is on the vendor's page.
What tells us the counts still match? A daily comparison of orders on the platform against orders in your systems is the only answer that survives silence.

The pattern is worth keeping once this gap is closed. Orders stopped syncing because a webhook stopped working is one instance of a larger shape. Any connection where one system waits to be told something can stop being told, and waiting looks identical to peace.

If you would rather have that mapped across everything that depends on one system calling another, that is what the process audit produces. In writing, with what each connection is worth when it fails.