Does a delivery app have to tell you before it closes your restaurant?
No, and restaurant operators looking for a notification clause will not find one, because none of the eight platforms whose partner terms and developer documentation we read publishes a duty to warn a restaurant before it is switched off. What exists is narrower and worth knowing precisely. One platform pushes a machine readable status change to an integration. Two send a prompt before a scheduled opening rather than before a closure. The rest document only that a closure can happen, that the platform can be the one doing it, and that the restaurant should contact support afterwards.
Do any partner terms promise notice before a platform closes a store?
Not in the material we could read. The clearest published text runs the other way. noon Food’s supplemental terms carry a clause headed “j. Suspension of Noon Food Services”, under which noon “at its sole discretion, reserves the right to temporarily or permanently suspend, in whole or in part, Merchant’s access to the Noon Food Services and Noon Food Tools”, listing four grounds including arrears and a defined “Brand Matter”. Source: foodrohelp.noon.com. The same document contains a clause headed “No Service Guarantee” stating that the platform “may be unavailable at any time and for any reason”.
Read those two together and the position is explicit rather than ambiguous. The platform reserves a right to suspend and disclaims availability. Neither sentence attaches a notice period, a warning, or a named recipient.
Which platforms document a notification at all, and who receives it?
Keeta does, and it is the strongest example in the set, but the recipient is a system rather than a person. Keeta publishes a webhook called “Store Status Update Notification”, event ID 1102, described as pushing “real-time notifications when a store’s operational status changes”. Its payload carries fromStatus and toStatus plus the same pair for the delivery and pickup sub statuses. Source: api-docs.mykeeta.com. If nobody has built a listener for event 1102, the notification is sent and lands nowhere.
The middleware layer is weaker still, and honest about it. Deliverect’s own guidance on closed stores says “Some channels inform Deliverect when a store closure is triggered from their platform”, surfacing it as a “Busy Mode Sync”, and adds that this is “just Deliverect syncing through the state of your channel and not Deliverect triggering the changes”. Source: help.deliverect.com. The operative word in that sentence is “some”. A restaurant cannot assume its integrator will be told, because the platforms that tell it are a subset nobody publishes.
What does a warning before closure look like when a platform does give one?
It looks like a prompt about opening, not a warning about closing, and that difference decides who it helps.
Deliveroo’s Open Reminder fires “30 minutes before your restaurant’s scheduled opening time”, keeps “sounding every 10 minutes until it is acknowledged”, offers two choices labelled “Ready to open at your scheduled time” and “Remain Closed”, and answers the obvious question directly: “Can I ignore the Open Reminder notification? No. If you don’t respond, your business will stay closed on the app until someone confirms you’re ready to open.” Source: help.deliveroo.com. Talabat and HungerStation both document an equivalent Check-in feature with the same 30 minute window, described as disabled by default and switched on through an account manager.
Snoonu comes closest to a genuine warning of a closure. Its partner portal carries the line “Please confirm the special hours for this store by reviewing and re-saving them. Failure to do so will result in an indefinite closure.” That is a stated consequence in advance, which is more than the others offer, and it still depends on somebody opening the portal to read it.
Why does the notice, where it exists, arrive somewhere nobody is watching?
Because these alerts are built for the branch device rather than for head office, and the branch device is the weakest link in a chain of any size. Deliveroo publishes no merchant application in either app store, and its mobile route for partners is a progressive web app installed from the browser. Careem publishes an Android merchant app and has no iOS merchant app at all, so a manager on an iPhone has the web portal or nothing.
The result is structural rather than accidental. A prompt designed to be answered by whoever is standing next to the tablet is invisible to the person who owns the numbers, and a chain that has delegated the tablet to the branch has also delegated the only channel through which a platform ever speaks about state.
What happens when the closure comes from the platform side and nothing is sent?
The restaurant finds out by looking, and several platforms document exactly that expectation. Careem’s partner portal answers a closed outlet with the tooltip “To reactivate your outlet, please reach out to Careem”. Deliveroo announced Forced Closure in its API changelog with the line “This new tool can only be enacted by Deliveroo”, and adds that a partner wanting to reopen “will need to contact Deliveroo by calling our Partner Support team”. Source: api-docs.deliveroo.com. On Jahez, visibility is a separate column from open and closed, and Deliverect’s Jahez troubleshooting tells operators to “Ask Jahez to set your store’s visibility status back to ‘Visible.'”
In each case the documentation describes the route back into trading. In none of them does it describe a message that starts the conversation. The discovery step belongs to the restaurant.
How long does a chain stay dark when nothing tells it?
Long enough for the notification question to be the expensive one. Across the markets we measure, a typical monitored restaurant listing loses about a full trading day over a month, and roughly a third of listings lose nothing at all, which means the loss concentrates on the listings nobody is watching. The average unexpected interruption in the UAE panel runs close to three hours. In Saudi Arabia the interruptions are rarer and much longer, five hours on an actively trading listing once persistently dead listings are excluded. Our published market figures are the UAE, Saudi Arabia and Kuwait reports.
Those lengths are not the duration of a fault. They are the duration of not knowing, because most of the states behind them are reversible in a minute once somebody sees them.
What should a chain ask for in writing instead of a notice?
Ask for the things a platform can actually grant, since a notification duty is not among them. A named escalation contact and a route that does not depend on the branch tablet. Whether Check-in is enabled on your vendors, because on Talabat and HungerStation it is documented as off by default and it determines whether a scheduled opening happens without a human. Which portal roles your head office holds, since on Deliveroo the bulk Site Status controls are limited to the Admin and Manager roles. And confirmation of who at the platform can restore a visibility flag or lift a forced closure out of hours.
Then supply the missing half yourself. Because no platform in this set commits to telling a restaurant that it has been switched off, the detection is the operator’s own problem to solve, and Kitchain (kitchain.co) solves it by reading each listing from the customer side against the hours that listing itself published, which is the one view that does not depend on being notified.