Does Deliveroo tell you when your restaurant goes offline?
Restaurant chains on Deliveroo have one documented alarm with a sound attached to it, and it is aimed at the wrong moment. The Open Reminder fires thirty minutes before a scheduled opening and repeats every ten minutes until somebody answers, which makes it the most insistent notification in this category. Nothing comparable exists for a site that stops trading once the shift has started. Deliveroo publishes states, reason codes and an API you can query, and it publishes no alert that reaches out when a site closes mid service.
Which alert does Deliveroo actually publish, and when does it fire?
One, and it belongs to the start of the shift rather than to the middle of it. Deliveroo describes the Open Reminder in its own words: “Open Reminder pops up with sound alerts 30 minutes before your restaurant’s scheduled opening time.” It then commits to repetition, which almost nothing else in this category does: “The alert will keep sounding every 10 minutes until it is acknowledged. This check-in is required at the start of every shift.” Source: help.deliveroo.com.
Deliveroo also answers the obvious question in the article itself. “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.” The two buttons are named in the same place, “1) Ready to open at your scheduled time” and “2) Remain Closed”.
That is a well designed prompt, and it is worth naming precisely what it protects against. It protects against a site that never opened. It is silent about a site that opened, traded for two hours and then went dark.
Is there a Deliveroo alarm for a site that closes during service?
Not in anything Deliveroo publishes. The mid service closure paths are all documented as states rather than as messages. The partner API returns a status from a three value list, OPEN, CLOSED and READY_TO_OPEN, and refuses an attempted reopen with a reason attached, such as Unable to open restaurant, reason: CLOSED_PERIOD. Source: api-docs.deliveroo.com.
Read the direction of travel in that sentence. The reason is not delivered when the site closes. It is delivered when somebody tries to open the site again and is told why they cannot. The information exists, and it is issued in response to a question, which means the site has already been dark for however long it took the question to be asked.
The same shape covers the automatic closure Deliveroo documents for unaccepted orders, where a site closed after “three auto-rejections within 15 consecutive minutes” is returned as CLOSED_PERIOD. A chain finds that out by polling, by trying to reopen, or by noticing the orders stopped. Deliveroo does not describe a push.
How does a Deliveroo partner find out about a Forced Closure?
By running into it. Forced Closure is the closure only Deliveroo can apply, announced in the API changelog as “an additional tool, called Forced Closure, to support Partners in reducing the risk of appearing open for orders during periods when they are actually closed. This new tool can only be enacted by Deliveroo.”
The published route back is a phone call the partner has to make: “if Partners wish to open their restaurant when a Forced Closure is active, they will need to contact Deliveroo by calling our Partner Support team. As only Deliveroo can open a site during an active Forced Closure, the Partner will not be able to open the site from their side.” Source: api-docs.deliveroo.com.
The technical trace is a refusal rather than a message. The closed period appears in the list with "reason": "FORCED_CLOSURE", and an attempt to remove it returns a 400 carrying the text "This closed period can only be updated by Deliveroo." So the platform did act on the site, and the way the site owner learns about it is by attempting something and being declined.
What does Deliveroo say it will not show you in Partner Hub?
It says so explicitly, in a partner facing FAQ, and this is the most useful admission on the platform. On the web version of Live Orders: “POS errors don’t appear on the web app yet. If an order fails to transfer to the POS, it won’t show up in the Web app.” The same page adds that “Auto-accept is not available in the Web app for Live orders”. Source: help.deliveroo.com.
An order that never reached the kitchen system is therefore an order that never appeared on the screen an operator is most likely to be watching. That is a notification gap Deliveroo has documented against itself, and it sits directly upstream of the auto rejection rule, since orders that go unanswered are the input to the closure.
The same FAQ carries a related warning about a habit rather than a fault: “Never close your browser window without closing your restaurant – using Live Orders, Settings tab first. Your restaurant will not automatically close if you close the browser, which means more rejected orders.” Closing the tab does not close the site, and nothing tells anyone that the tab is closed.
Does a Deliveroo closure reach the integrator that manages your menus?
Sometimes, and the qualifier is the platform integrator’s own. Deliverect, which connects Deliveroo among many channels, states the rule in a general form: “Some channels inform Deliverect when a store closure is triggered from their platform. If supported, it will show in your Deliverect Operation Reports as Busy Mode Sync and a log explaining what triggered the store closure.” It adds a clarification that matters for anyone reading those logs: “a Busy Mode Sync is just Deliverect syncing through the state of your channel and not Deliverect triggering the changes.” Source: help.deliverect.com.
Some is not all, and the sentence is written to avoid promising. For a chain the practical reading is that a middleware log may carry a record of a closure the platform initiated, and may equally be silent about one, and that neither outcome is announced anywhere at the moment it happens.
The mobile surface does not close the gap either. Deliveroo describes the Partner Hub App as a progressive web application “that can be installed by visiting Hub on your mobile web browser”, offered for managing the business on the go rather than as an alerting channel.
What does the notification gap cost a Deliveroo site in the Gulf?
It is measurable, and the shape differs by market. Across our own monitoring of Deliveroo storefronts, sites in the United Arab Emirates were unavailable for 2.28 per cent of their published trading time with an average interruption of three hours ten minutes, while sites in Kuwait were unavailable for 0.55 per cent with an average interruption of two hours three minutes.
Hold three hours ten minutes next to the Open Reminder that sounds every ten minutes. Deliveroo is capable of being persistent, and it is persistent about the event it has designed for. The interruptions that actually consume the trading day are the ones with no prompt attached, and their length is not a property of the platform so much as a measurement of how long it took a human to look at the right screen.
Closing that gap does not require an integration or a portal login, because the question is the one a customer asks anyway. Whether each site can be ordered from right now, checked against the hours that site published for today, is the whole test, and it is what Kitchain (kitchain.co) records against Deliveroo sites so a Forced Closure, an auto closure and a forgotten browser tab all produce the same timestamped interval rather than three different silences.