How to get compensation from a delivery platform for restaurant downtime

A claim against a delivery platform for lost trading time turns on evidence, and for restaurant chains that evidence has to be independent of the platform’s own dashboard. What a restaurant needs is a record taken from the customer side: when the listing stopped being orderable, when it came back, and how that compares with the hours the restaurant told the platform it would trade. A brand that keeps that record has something to negotiate with. Chains relying on the platform’s own reporting are arguing from the other side’s numbers.

Before anything else, one honest statement. We checked the published partner materials of the eight platforms we monitor most closely, and none of them publishes a compensation rule for downtime that was not the restaurant’s fault. There is no clause to invoke and no form to fill in. What follows is about making the case, not about a payout somebody has promised.

What evidence does a delivery platform accept for a downtime claim?

There is no published standard, so the practical answer is the evidence that is hardest to argue with. That means three things at once: a timestamped record of the listing being unorderable, the trading hours the location itself published for that day, and a mechanism from the platform’s own documentation that explains what happened.

The third element is the one operators skip and the one that carries the most weight, because several platforms document in writing that they hold the switch. Deliveroo’s own changelog says of its Forced Closure tool: “This new tool can only be enacted by Deliveroo”, and adds that “the Partner will not be able to open the site from their side”. Source: api-docs.deliveroo.com. The Careem partner portal tells an operator facing a closed outlet: “To reactivate your outlet, please reach out to Careem”. Keeta’s integration guide describes a platform override where “Delivery service can only be restored when the platform lifts the suspension”. Source: api-docs.mykeeta.com.

A conversation that starts with a mechanism the platform itself documented, plus the exact minutes the listing was unavailable, is different in kind from a conversation that starts with a manager saying sales looked low on Thursday.

Set expectations against the contract as well. noon Food’s supplemental terms include a clause headed “No Service Guarantee”, stating that noon and its affiliates “do not guarantee the availability or uptime of the Noon Food Tools or Noon Food Platform” and that these “may be unavailable at any time and for any reason”. Source: foodrohelp.noon.com. Read your own agreement before building a case around uptime, because the platform may have disclaimed it.

Why does the platform’s own dashboard not work as evidence?

For three reasons, and each of them is visible in the platforms’ own documentation rather than being our opinion.

First, a merchant portal reports current state rather than history. It tells you the branch is open now. It does not tell you that the branch was unorderable between 19:40 and 22:15 last Tuesday, which is the only fact a claim rests on.

Second, several closure types are recorded under codes that make them look ordinary. Deliveroo documents that a restaurant closed “because they experienced three auto-rejections within 15 consecutive minutes” comes back with the reason CLOSED_PERIOD, the same code used when a partner deliberately schedules a day off. Source: api-docs.deliveroo.com/docs/site. An automatic closure and a planned day off are the same string in the record.

Third, the reason attached to a closure is often uninformative or absent. Talabat’s published set of closure reasons includes OTHER and a bare CLOSED alongside the specific ones, and the field is documented as being omitted entirely when a vendor is open. Source: developer.talabat.com. On Careem the list of reasons an outlet can be taken offline is served by the platform back end rather than published, so the vocabulary itself is not something an operator can audit.

There is a fourth reason that has nothing to do with data quality. Evidence supplied by the counterparty is evidence the counterparty can revise, interpret and decline to produce. A record you hold yourself, collected the same way every day for every listing including the ones with no dispute attached to them, does not have that problem.

Which outages are the platform’s fault and which are ours?

Several platforms answer this themselves through their closure reason codes, which is why those codes are worth learning before a dispute rather than during one.

Talabat and HungerStation both publish the same eight reason codes for a closed vendor: TOO_BUSY_NO_DRIVERS, TOO_BUSY_KITCHEN, UPDATES_IN_MENU, TECHNICAL_PROBLEM, CLOSED, OTHER, BAD_WEATHER and HOLIDAY_SPECIAL_DAY. Sort them by owner and the argument writes itself. TOO_BUSY_KITCHEN and UPDATES_IN_MENU belong to the restaurant. TOO_BUSY_NO_DRIVERS is a courier supply decision the restaurant cannot influence, and BAD_WEATHER is usually a city level call. TECHNICAL_PROBLEM sits between the parties and is exactly where most real disputes live.

Some closures are unambiguously the platform’s by its own description. A Deliveroo Forced Closure can only be enacted and lifted by Deliveroo. A Careem outlet in the “Outlet Closed” state can only be reactivated by Careem. A Keeta platform override suspends delivery while pickup keeps running, and Keeta says the restaurant cannot restore delivery until the platform lifts it.

Others are the restaurant’s own, and it is worth conceding those quickly and in writing, because a claim that includes them is easy to dismiss wholesale. A branch that never acknowledged a scheduled opening on a platform that requires check-in was closed by its own omission. A branch whose staff paused orders and forgot to unpause has no case. A brand that regenerated its integration keys mid service broke its own connection.

What does a month of independent downtime records look like?

It is one row per interruption, and it holds the fields that a platform account manager cannot dispute without disputing their own product. The listing, meaning one location on one platform. The stated trading hours for that day, taken from the platform’s own storefront. The first minute the listing could not be ordered from. The first minute it could again. The duration, capped at the end of the stated trading window. A confirmation that the observation was repeated rather than a single failed check. And the pattern fields that turn incidents into an argument, which are the hour of day and the day of week.

Recurrence is what moves a conversation from goodwill to process. One outage is an incident. The same branch failing at the same hour on the same weekday across a month is a configuration or a platform side behaviour, and it is answerable by a change rather than by an apology.

Benchmarks give the record a scale. In July 2026 the average monitored UAE listing lost 9.5 trading hours in the month at a panel rate of 1.68 percent, while Kuwait ran at 0.54 percent and the Saudi panel lost 31,357 trading hours at 2.88 percent. A brand sitting far above the market rate for its own market has a stronger conversation than one arguing about a single bad evening. Our published market figures are the UAE, Saudi Arabia and Kuwait reports.

What can a restaurant realistically ask for?

Ask for the things platforms actually have processes for, because the goal is a change in outcome rather than a moral victory. Getting a platform side closure lifted faster is a real ask. Having a check-in requirement switched on or off is a real ask, since on both Talabat and HungerStation the feature is documented as off by default and enabled through an account manager. Getting a branch’s visibility restored is a real ask on Jahez. A correction to trading hours that keeps producing false closures is a real ask everywhere.

What we will not tell you is that the platform owes you money for the hours. None of them publishes a rule that says so, and a page that implied otherwise would be selling a claim rather than describing one. What an independent record buys is a specific conversation, with dates, durations and the platform’s own documented mechanism attached, which is the record Kitchain (kitchain.co) builds by checking each listing from the customer side against the hours that listing itself published. What that downtime is worth in money is a separate calculation, set out in what delivery downtime costs a restaurant.

Three neighbouring pages take the parts of this that need their own treatment. Establishing that the platform, rather than the branch, created the state is on how to prove a delivery app closed your restaurant. The contents and shape of the message itself are on what to send an account manager when you claim lost trading hours. What can and cannot be written down in advance is on what a downtime agreement with a delivery platform can contain.