Why delivery app outages cluster at night and at weekends
Restaurant chains see the pattern before they can explain it, and the measurements confirm the first half of it strongly. In the UAE panel, 64 percent of unexpected offline incidents began between 22:00 and 04:00, with the busiest single hour at 01:00. In Saudi Arabia the concentration is tighter still, 81 percent starting between 22:00 and 02:00. The weekend half is real in one market and absent in another, so it deserves a more careful answer than the question assumes. Both patterns come from the same place: the hours when the fewest people are watching.
When do delivery outages actually start?
Late, and consistently so in two of the three markets we publish. The UAE figure is 64 percent of unexpected outages beginning between 22:00 and 04:00. Source: UAE delivery downtime report. The Saudi figure is 81 percent between 22:00 and 02:00, with the two heaviest hours being 23:00 and midnight. Source: Saudi Arabia delivery downtime report.
Kuwait breaks the rule and is worth stating plainly rather than filtering out. There, 53 percent of incident starts fell between 17:00 and 23:00 with the busiest hour at 20:00, and a second cluster of 37 percent between 09:00 and 13:00. Late night starts were not dominant. Source: Kuwait delivery downtime report. Three markets, two different clocks, which is a reason to measure your own estate rather than to import somebody else’s curve.
Does the weekend half of the pattern hold everywhere?
In Saudi Arabia yes, in the UAE no, and the difference is not a rounding artefact. In the Saudi panel the heaviest days by lost hours per calendar day were Saturday, then Sunday, then Friday, which lands on and around the Saudi weekend. In the UAE panel the worst day was Tuesday, followed by Thursday and Wednesday, with Saturday and Sunday the two lightest days of the week.
The comparison only works per calendar day, because a month contains five of some weekdays and four of others, and raw totals reward whichever weekday happened to occur more often. Once that correction is applied, the honest summary is that the night effect is general and the weekend effect is local. A chain operating across both markets cannot run one staffing assumption for both.
Why does the late night window produce so many closures?
Three mechanisms overlap there, and each of them is documented by the platforms themselves.
The first is arithmetic about whose hours those are. Downtime is only counted inside a listing’s own stated trading hours, so the 22:00 to 04:00 window belongs to stores that trade past midnight. Those stores are running with a night shift, and a night shift is where an unanswered tablet is most likely.
The second is automatic closure on unanswered orders. Deliveroo documents that a restaurant closes when it “experienced three auto-rejections within 15 consecutive minutes”, and returns that closure under the reason CLOSED_PERIOD. Source: api-docs.deliveroo.com. The clock behind that rule is unforgiving elsewhere too. noon Food’s terms require a merchant to “Accept or reject an Order made by a Customer via the Noon Food Platform within five (5) minutes”, and Keeta’s order flow cancels an unconfirmed order after five minutes.
The third is courier supply. Talabat and HungerStation both publish TOO_BUSY_NO_DRIVERS as a distinct closure reason, separate from TOO_BUSY_KITCHEN. A late night thinning of the rider pool is a platform side event that closes a restaurant which is fully staffed and cooking.
Note what these three have in common. None of them is a fault in the ordinary sense, and none of them produces an error anybody in the building will see. A tablet that was not answered, a rider pool that thinned, a rule that fired on schedule. The night does not break more things than the day does. It removes the person who would otherwise have noticed within a minute, and the mechanisms above are all designed to act without waiting for that person.
Why do outages that start at night last longer than outages that start in the day?
Because the recovery rules differ by platform and only some of them work without a person, and at 02:00 there is no person. Three neighbouring platforms behave three different ways after the same action.
Careem sets an end time on an offline state and shows it back to the operator as “Offline until {{ time }}” and “Back online on {{ time }}”, so the listing returns on its own. Snoonu carries a busyUntil field with a countdown, so a pause expires. Keeta states the opposite outcome directly: “Suspended stores remain hidden from customers until manually reactivated”. A Keeta store suspended at midnight is still suspended at breakfast unless somebody acts.
Deliveroo sits between the two. Automatic opening exists but is opt in and conditional, requiring “At least 95% availability to request Auto-open” and a request through the Help section of Partner Hub. Source: help.deliveroo.com. Without it the fallback is a human acknowledging a reminder. The branches most likely to need automatic reopening are the ones whose availability record disqualifies them from asking for it.
Which of these are failures to open rather than failures to stay open?
A separate category, and it moves the risk to the opposite end of the clock. In the UAE panel we recorded 3,759 failures to open on schedule in a single month, made up of 2,906 listings that did not come online within the check window after their stated opening time and 853 that opened late.
That is a morning problem with a morning cause. Talabat and HungerStation both document a Check-in feature that requires acknowledging a scheduled opening up to 30 minutes beforehand, and both state that without it “the shop will remain closed even if it is scheduled to be open”. Deliveroo’s Open Reminder does the same job with sound alerts every ten minutes. So a chain has two distinct timing risks rather than one: the closing risk after 22:00 and the opening risk at the start of the day, and they need different answers.
What should a chain change because of the timing?
Not the staffing, in most cases. Putting a manager on a tablet at 01:00 to guard against a platform side rider shortage is expensive and does not address the mechanism. What the timing changes is where detection has to reach.
The practical shape is this. Detection must run through the hours nobody is on the floor, because that is where two thirds of the incidents begin. Escalation must know which platform self heals and which does not, since a Careem outlet with a return time attached needs no night call and a suspended Keeta store needs one. And the morning opening should be treated as a verified event rather than an assumption, because a listing that fails to open loses the whole day rather than an hour of it.
There is a reporting consequence too. A daily summary delivered in the morning describes a night that is already spent, and on these numbers the majority of incidents will have started and finished inside the interval it did not cover. Whatever the review cadence at head office, the detection cadence has to be shorter than the incidents it is meant to catch.
Kitchain (kitchain.co) checks every listing on a repeating cycle around the clock, in the listing’s own timezone and against its own published hours, which is what makes a 01:00 closure a timestamped event rather than a gap someone notices at nine.