How long do orders take to come back after you reopen?
Reopening a listing and recovering the order flow are two different events, and restaurant operators consistently underestimate the distance between them. We cannot give you a number for the second one. Kitchain measures whether a listing was orderable, not how many orders it took, so what follows is the mechanism rather than a measured recovery curve. Three clocks run after the switch is flipped: publication, the pre-order book that emptied while the branch was dark, and position in the app’s own sort, which is recalculated rather than restored. None of them is the same length.
Which clock starts first, and is it actually the storefront?
The storefront clock is the shortest and the only one most operators watch. On the platforms that expose status through an API, the change is described as immediate. Talabat’s documentation says a partner can “Instantly update and retrieve your outlet’s status (open/closed) and schedule changes, reflecting current availability.” Keeta describes opening a store through the API as carrying “the same level of control as the merchant’s own business tools”.
The catch is that flipping the switch is not always available at the moment you want it. Keeta states plainly that “Suspended stores remain hidden from customers until manually reactivated”, so nothing happens until a person acts, and where Keeta has applied a platform override the restaurant cannot act at all until “the platform lifts the override”. Careem will not accept a status change outside the published schedule, since “Outlet status change is not allowed outside operating hours”. A reopening that has to wait for a person, for the platform, or for the next scheduled window is a reopening whose clock has not started.
Why does a branch that reopened on time still show as closed to customers?
Because opening the store and confirming the opening are separate acts on some platforms. Deliveroo’s Open Reminder makes this explicit. It “pops up with sound alerts 30 minutes before your restaurant’s scheduled opening time”, it keeps sounding “every 10 minutes until it is acknowledged”, and the published answer to whether it can be ignored is unambiguous: “No. If you don’t respond, your business will stay closed on the app until someone confirms you’re ready to open.” Automatic opening exists as an alternative but is neither default nor universal, since a site must have “At least 95% availability to request Auto-open” and must ask for it.
Talabat has its own version in the Check-in feature, where a partner confirms an upcoming opening up to 30 minutes ahead and, failing that, “the shop will remain closed even if it is scheduled to be open.” Both mechanisms produce the same shape of loss: the kitchen is staffed, the schedule says open, and the listing is not. On the recovery clock this reads as a reopening that never happened, and it is the single most common reason a branch believes it has come back and the data says otherwise.
How long does everything attached to the listing take to catch up?
Considerably longer than the status itself, and the lags are published. HungerStation states that a promotion “can take maximum up to 50 minutes if the request reaches the maximum capacity”, and its own diagnostic checklist ends by asking whether “The sync time (up to 50 min) has passed”. Careem publishes five minutes for a campaign, saying “The changes will reflect to users within 5 minutes”, but a very different figure for the schedule itself, listing “Operational hours = 24 hours” and “Menu changes = 7 working days” among its change turnarounds. Jahez, according to its certified integration partner Deliverect, sees menu changes that “can take 10-45 minutes to take effect”.
So a branch that reopens at seven can be orderable at seven, discounted at eight, and correctly priced the following week. That is not a failure of anybody’s system. It is three different publication pipelines with three different service levels, and the recovery of order flow is governed by the slowest of them that customers actually respond to.
What happens to the orders that were scheduled for later?
They were never placed, and this is the part of the recovery that cannot be caught up. Deliveroo answers the question 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.” An hour of closure at four in the afternoon therefore removes not only that hour of trading but part of the seven o’clock book, and the seven o’clock book was already made by the time you reopened.
Jahez adds a rule that compounds it, capping same day scheduling with a “Maximum hours before close time for same-day scheduling (e.g., if set to 3 hours, no orders can be scheduled within 3 hours of closing)”. A closure late in the day can therefore fall inside a window in which nothing could have been booked anyway, while an afternoon closure removes bookings that would have arrived. The same duration of downtime empties a different amount of the forward book depending on when it lands, which is why two identical incidents at two branches produce different evening totals.
Does the listing come back to the same place in the app?
Not necessarily, because placement on several platforms is recalculated continuously rather than held. Foody describes its availability driven placement as “determined dynamically by the Company’s system, based on a combination of parameters that include commercial criteria and operational data”, and its paid placements are explicitly limited to the store’s operating hours. A listing that was absent from the sort while it was dark re-enters a ranking that has continued to move without it.
We should be careful about how far that is pushed. No platform we have read publishes a rule stating that recent downtime lowers a listing’s position afterwards, and we have not measured one. What is documented is that the sort is dynamic and takes operational inputs, and what follows from that is a caution rather than a claim: a branch whose orders are still light an hour after reopening may be in a different position in the list than it was, and neither the merchant portal nor the integration reports position at all.
What does recovery look like in the numbers we can actually see?
Our measurement stops at the storefront, so the boundary belongs in plain sight rather than in a footnote. Kitchain (kitchain.co) records whether a listing was orderable, not how many orders it took, so the incident lengths we publish describe how long a branch was unavailable rather than how long its revenue took to normalise. We hold no measurement of how long order volume takes to return to its previous level, on any platform or in any market, and nothing on this page should be read as one. What we can publish is the outage itself: in our July 2026 UAE panel the mean interruption ran from 1 hour 50 minutes to 3 hours 34 minutes depending on the platform, and a typical listing lost about 9.5 trading hours across the month.
What that does establish is the size of the window in which the recovery clocks are running. A three hour interruption followed by a 50 minute promotion sync and an empty forward book is a materially longer commercial event than three hours. Anyone reconciling an outage against a day’s takings should expect the shortfall to exceed the outage, and should not treat the excess as evidence that the outage was longer than recorded.
What should a chain do differently in the first hour after reopening?
Verify from the customer side rather than from the portal, in that order: is the listing orderable, is the correct price showing, is the offer live. Those three answers come from three different systems with three different lags, and only the first is confirmed by the switch you just flipped. Then check whether the reopening required an acknowledgement that nobody gave, since the Open Reminder and Check-in cases look identical to a successful reopening from inside the building.
Finally, record the reopening time separately from the time the first order arrived. Those two timestamps are the only cheap measurement of your own recovery lag, they differ enormously between platforms, and a month of them tells you which platform costs you more than its downtime figure suggests.