A delivery app is down across the whole city. What should a chain do?
When a platform fails across a city, restaurant chains lose money twice: once to the outage and once to their own response. The two expensive mistakes are predictable. Flooding the support queue with one ticket per branch produces nothing, and bulk closing the estate produces a second outage that outlives the first, because on several of these platforms closing is easy and reopening is governed by rules that do not run in reverse. The useful actions are narrower than they feel: confirm the scope, protect the reopening, move what volume can move, and record the interval.
How do you confirm the scope before acting on it?
By checking restaurants that are not yours. Open the platform’s consumer app at an address you serve, signed out, and look at unrelated brands. If the category is empty or nothing will load a menu, the fault is above every restaurant in it. If unrelated brands are trading, this is not a city wide event and the response should be the ordinary single branch one.
The whole decision that follows rests on this answer, so it is worth the ninety seconds. The detailed version of the check is set out in how to check whether a delivery app is down right now.
What is the first decision, and why is it not a ticket?
Whether to close your own listings or leave them alone. Nothing at your end caused this and nothing at your end will fix it, so the only lever you hold is the state of your listings during and after the event.
The default answer is to leave them as they are. A listing that is unreachable because the platform is unreachable costs you the same trading hours whether you closed it or not, and closing adds a step you will have to undo under time pressure later. The exception is when your kitchen genuinely cannot serve, for instance because the outage is regional and your riders or your till are affected too, in which case a closure is an honest signal rather than a defensive reflex.
Why is bulk closing during an outage a trap on some platforms?
Because reopening is constrained in ways that closing is not, and the constraints differ. Careem’s portal refuses status changes with “Outlet status change is not allowed outside operating hours”, so an outlet closed late in the evening may not be reopenable that night. Source: Careem Partner Portal. Talabat’s OPEN status is documented as working only “if it’s within opening hours according to schedule”. Source: developer.talabat.com. Keeta states plainly that “Suspended stores remain hidden from customers until manually reactivated”, so every store closed in bulk needs a deliberate action to come back. Source: api-docs.mykeeta.com.
One platform is the deliberate exception and it is worth knowing which. Deliveroo built a bulk tool for exactly this scenario and says so: “Site Status lets you open or close multiple sites in bulk, fast. Use it to close sites the moment something stops you fulfilling orders, like a service outage, so customers don’t order from a site that can’t deliver.” The controls are labelled “Open selected sites” and “Close selected sites”. Source: help.deliveroo.com.
So the rule is per platform rather than general. Where the platform has built and recommends the bulk action, use it. Where reopening is time gated or manual, do not create a hundred manual reopenings for yourself.
What happens to pre-orders and scheduled orders?
They stop too, and this is the cost operators forget when they close defensively. Deliveroo answers it directly: “Will bulk closing the sites also disable scheduled orders? Yes. If a site is closed, no scheduled orders can be placed until the site re-opens again.”
That extends the damage past the outage window. A tomorrow lunchtime pre-order that a customer could not place tonight is not recovered when the platform returns. Talabat’s own storefront dictionary shows the platform trying to hold that demand rather than release it, with a closed state message for its Talabat Go service telling customers “You can continue adding items to your cart and order when delivery service is resumed.” A closed restaurant listing offers no such holding pattern.
Where should the volume go?
To the platforms still trading, and the honest answer is that this lever is only as strong as the estate’s spread. A chain on four platforms in a city has somewhere for demand to land. A chain on one has nothing to move and its whole action list is the recording step.
Redirection is worth doing quickly rather than well. A social post and a message to whatever customer list exists will move a fraction of the evening, and that fraction is free. What it is not worth is spending the outage building a campaign, since the event will usually be over before the campaign is.
What should the branches be told?
Two sentences, and one of them is a restriction. First, orders will not arrive on that platform and the kitchen should stop prepping against a delivery forecast that is no longer true, because otherwise the waste lands at the end of the night. Second, do not change the tablet.
The second instruction matters more than it sounds. A branch manager toggling states during a platform failure creates a local closure that persists after the platform recovers, and that closure will be indistinguishable from the outage in the record. Chains routinely find that their longest listings in a mass event were the ones where somebody helped.
When is a ticket worth opening, and what should it say?
One ticket for the estate, not one per branch, and it should ask for two things rather than report a problem the platform already knows about. Ask for confirmation that the incident was platform side and for the window it covered, because that sentence is the piece you cannot obtain any other way and the piece an account manager conversation later will turn on.
Everything else can wait. During a mass failure the support queue is the least responsive it will be all month, and a message asking for an explanation lands better once the platform has one to give.
What does a mass event look like afterwards, and why does that matter?
It distorts the month, which is why it has to be labelled at the time rather than explained later. In Kuwait, a single day in July 2026 produced 1,149 lost trading hours, 17 percent of the entire month’s total, from only 376 incidents. Source: Kuwait delivery downtime report.
That is the fingerprint: very few incidents carrying very many hours, the opposite of ordinary churn. A chain that reports a monthly availability figure containing an unlabelled event of that size is comparing two different things, and any decision made on the comparison will be wrong.
How do you come back?
Branch by branch, from the customer side, rather than by checking one storefront and standing the team down. Recovery after a mass failure is usually staggered, and on the platforms where reopening is manual some listings will not return at all without a person. The long tail of lost hours after a city wide event comes almost entirely from the listings nobody rechecked.
Then close the record: platform, start, end, which branches were affected, whether unrelated restaurants were affected at the same time, and whether anyone in your business changed a state during the window. That last field is what keeps the event honest a month later. Kitchain (kitchain.co) supplies the first four automatically, because it reads every listing on the same cycle whether or not anyone is watching that night.