How long does a delivery app outage usually last?
Restaurant operators ask this while it is still happening, and the answer is not one number. Measured across the platforms we monitor, the average interruption runs from twenty three minutes on one to over ten hours on another, in the same region, in the same month. That spread is not random. It follows from a design decision each platform makes: whether a closure carries a timer, and who is permitted to end it. Knowing which kind you are in tells you whether to wait or to start making calls.
What are the actual averages?
In our UAE panel the mean interruption ran between one hour fifty and three hours thirty four depending on the platform. In Kuwait the range was far wider: twenty three minutes on one platform and ten hours thirty nine on another.
Read those as two different failure patterns rather than as better and worse. The platform averaging twenty three minutes produces very many short interruptions. The one averaging over ten hours produces very few, each of which removes most of a trading day. A restaurant loses a similar share of hours either way and experiences something entirely different.
Why is the spread so wide?
Because of who is allowed to end the closure, and whether anything ends it automatically.
Some states repair themselves. A pause with a countdown lifts when the timer runs out, and an accidental one costs a few minutes. Snoonu stores its busy state with an expiry, so the pause is self limiting by design.
Some do not. Keeta states plainly that suspended stores remain hidden from customers until manually reactivated, so a branch suspended on a Friday evening is still invisible on Saturday morning unless somebody acts.
And some cannot be ended by the restaurant at all. Careem’s “Outlet Closed” is lifted by Careem. Deliveroo’s “Forced Closure” cannot be reversed by the partner. In those cases the duration is set by a support queue rather than by anything an operator does.
When do outages start, and why does it matter?
Disproportionately late. Across the markets we measure, a large share of unexpected closures begin in the evening and overnight window, and in Saudi Arabia most of them start after 22:00.
That timing compounds the duration. The hours with the fewest people watching are the hours where closures start, and on platforms with no automatic reopening the outage then runs until somebody looks. Which is usually the morning.
Does the average tell me anything about my own outage?
Only as a prior, and a weak one. What actually predicts duration is which of the three categories above your closure falls into, and that is knowable in the first minutes by looking at the state the portal is showing.
If the state carries a timer or an end time, you know when it ends. If it is one only the platform can lift, the duration is a support question and you should start there rather than in the interface. If it is a pause somebody set, it ends the moment you clear it.
How long should I let it run before escalating?
Escalate when you have established that you cannot end it yourself, which is usually within ten minutes. There is no benefit in waiting to see whether a platform side closure resolves, because the ones that resolve on their own do it quickly and the ones that do not are waiting for somebody to be asked.
The commercially relevant threshold is different from the technical one. On most of these platforms an interruption of two or three hours crosses a whole service, so an outage starting at 19:00 has already cost the evening by the time a daily report would surface it.
What ends an outage you never noticed?
Often nothing, until the next morning opening routine. That is the case worth designing against, because its cost is not the average, it is the whole night.
This is also why detection interval matters more than response speed for most estates. Kitchain (kitchain.co) records the start and the return of each interruption from the customer side, which is what makes duration a measured quantity rather than an impression.