How to get Deliveroo to put your restaurant back online
Restaurant chains on Deliveroo have an advantage almost nobody else in this category gives them: when an attempt to open a site fails, Deliveroo tells you why in a fixed vocabulary. Its Site API documents four reasons an open call is refused, and each one points at a different fix. One of those states cannot be cleared by the partner at all. Deliveroo says so in the plainest terms available, writing that during an active Forced Closure “the Partner will not be able to open the site from their side” and naming a call to Partner Support as the route.
Deliveroo publishes four reasons why an attempt to open a site is refused
They are worth memorising because they convert a dead button into a diagnosis. The Site API documentation lists the cases and the string each returns: closure because of opening hours gives “Unable to open restaurant, reason: OPENING_HOURS”, vacation mode enabled by either party gives “Unable to open restaurant, reason: VACATION_MODE”, a partner set day off taken through Hub or the tablet gives “Unable to open restaurant, reason: CLOSED_PERIOD”, and a site closed after “three auto-rejections within 15 consecutive minutes” also gives “Unable to open restaurant, reason: CLOSED_PERIOD”. Source: api-docs.deliveroo.com.
Three different faults, three different owners, and only two distinct codes between them. OPENING_HOURS means the schedule is the blocker and no status action will work until Special Opening Hours or the weekly hours are edited. VACATION_MODE means a flag was set that survives shifts and weeks. CLOSED_PERIOD is the ambiguous one, since the same code covers a deliberate day off and an enforcement closure triggered by unaccepted orders, and separating those two requires looking at the days off list rather than at the error.
There is a fifth condition that is not a reason code at all but a hard rule: “Please note that it is not allowed to open a site outside of its opening hours, the call will return 400 (bad request) error.” A brand automating recovery has to reconcile with the schedule before it reconciles with the status.
Where in Partner Hub do you press open for one site or for fifty?
In Settings, under a tab Deliveroo named for exactly this job. The help article is called “Bulk Open and Close Sites with Site Status” and gives the navigation verbatim: “Navigate to the “Settings” page located on the left-hand side of the navigation bar. Inside the “Settings” page, you will find the “Site Status” tab.” The controls on it are labelled “Open selected sites” and “Close selected sites”, against a list column headed “All Sites”. Source: help.deliveroo.com.
Deliveroo built it for incidents rather than for routine trading, saying the section “enables users to open and close multiple partner sites in bulk” and that it “is particularly useful for managing large groups of sites during incidents and outages”. For a group recovering from a citywide network fault that is the surface to use, because opening forty sites one by one is how three of them get missed.
One consequence to plan for while a site is down. Deliveroo confirms that a closure also removes future orders: “Will bulk closing the sites also disable scheduled orders? Yes. If a site is closed, no scheduled orders can be placed until the site re-opens again.” A long reopen therefore costs tomorrow’s pre orders as well as today’s trade.
Which Deliveroo roles can press it, and which surface wins?
Access is by role and Deliveroo names them: “Hub users with the Admin, Admin (limited), Manager, or Manager (limited) role can access the Site Status feature from the “Settings” page in Hub.” An account without one of those four roles will not see the tab, which is a quiet cause of a recovery that stalls because the person who noticed cannot act.
The tablet remains a parallel and independent channel. Deliveroo states in the same article that “a store can still be manually opened or closed using the Deliveroo tablet”, so a site can be reopened centrally and closed again locally within the same minute, and neither actor gets told about the other. For a franchise group that is the most common cause of a site that reopens and then does not stay open.
There is also a habit worth writing into the closing routine, because Deliveroo publishes the failure mode. The Live Orders guidance warns partners: “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.” A site left nominally open with nobody watching produces the rejections that trigger the closure in the first place.
What do you say when you call Deliveroo about a Forced Closure?
Say the closure is a Forced Closure and say it early, because that word changes who has to act. Deliveroo introduced the tool in its API changelog and described its ownership without hedging: “This new tool can only be enacted by Deliveroo.” It then set out the consequence: “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.” Source: api-docs.deliveroo.com changelog.
An integrated brand can confirm the state before calling rather than guessing at it, which shortens the conversation considerably. The closure appears in the days off list carrying "reason": "FORCED_CLOSURE", and any attempt to remove it is rejected with the message “This closed period can only be updated by Deliveroo.” Quoting that string is a faster opening than describing a symptom.
What Deliveroo does not publish is the rest of the process. There is no response time for a Forced Closure request, no ticket category, no evidence list and no phone number anywhere in the developer material. Prepare for it as for any support call with no service level attached: have the site identifier, the moment the closure started and the reason string, and escalate through your existing account contact if the call does not resolve it.
How do you stop needing the press at all on Deliveroo?
By qualifying for Auto-open, which Deliveroo describes as opening “your site on the Deliveroo app the moment your scheduled opening time begins, so no one has to remember to do it manually”. It is not on by default and it is not granted on request alone. Deliveroo publishes the threshold as “At least 95% availability to request Auto-open”, checked against the Availability report in the Reports section, and the request route as “Go to the Help section in Partner Hub, Submit a request asking for Auto-open to be enabled”. Source: help.deliveroo.com.
That threshold creates a trap worth naming. Availability is the metric damaged by exactly the outages Auto-open would prevent, so a group that most needs it is the group least likely to qualify, and a site that slips under 95 percent has lost the tool that would have kept it above 95 percent.
Until Auto-open is granted, opening is a confirmation rather than an event. Deliveroo’s Open Reminder sounds thirty minutes before the scheduled opening, repeats “every 10 minutes until it is acknowledged”, 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.” A scheduled Day Off also cancels Auto-open for that day, which is how a site with the feature enabled still fails to open.
What should a Deliveroo chain measure about its own reopen times?
The gap between the site becoming unorderable and the site becoming orderable again, per site, against the hours that site published. Deliveroo gives a brand more raw material than most platforms, but every piece of it describes state rather than duration, and duration is the number that turns an anecdote into a case.
The two shapes worth separating in that record are the ones with different owners. A site that reopened four minutes after it closed had somebody watching. A site that reopened at the start of the next day had an unanswered Open Reminder or an unnoticed day off. A site that stayed shut through a full service until a phone call ended it was a Forced Closure, and that one belongs in a different conversation with Deliveroo than the other two. Across our UAE panel a Deliveroo site is unavailable for 2.28 percent of its trading time with a mean incident of 3 hours 10 minutes, and in Kuwait the same platform runs at 0.55 percent with a mean of 2 hours 03 minutes, so the same brand can hold very different exposure in two markets. Kitchain (kitchain.co) reconstructs those intervals on Deliveroo storefronts from the outside, which is how a brand can say which of the three shapes a given outage had.