Some of your branches are offline on Deliveroo and the rest are fine
Restaurant chains selling on Deliveroo are running an estate of independent sites rather than one brand with many addresses. Deliveroo scopes almost every availability setting to the site: opening hours, days off, vacation mode, whether the site has a tablet, whether Auto-open is switched on, and whether a Forced Closure is sitting on it. Two branches with the same menu, the same hours and the same staff can therefore behave completely differently on the same evening, and nothing in the app tells a customer which of the two they are looking at.
Which Deliveroo controls are set per site and which are set once for the brand?
Nearly all of them are per site, and the API says so in its own shape. Deliveroo’s Site API documents the reasons an attempt to open a restaurant is refused, and every one of them is a property of an individual site: OPENING_HOURS where the site is closed by its schedule, VACATION_MODE where vacation mode is enabled by Deliveroo or the partner, and CLOSED_PERIOD covering both a day off taken through Hub or the tablet and a site closed after three auto rejections inside fifteen consecutive minutes. Source: api-docs.deliveroo.com.
That list is the anatomy of a split estate. Four distinct mechanisms, four different owners, and all four evaluated site by site rather than brand by brand. A brand cannot be in vacation mode. A site can.
Hub does give a chain one genuinely collective tool. Deliveroo’s help centre describes a “Site Status” tab that “lets you open or close multiple sites in bulk, fast”, with buttons labelled “Open selected sites” and “Close selected sites” and a list column headed “All Sites”. Source: help.deliveroo.com. It is a bulk action, not a bulk setting. It changes many sites at once and then leaves each of them to drift again.
Why does one Deliveroo site open itself in the morning while another waits for a person?
Because Auto-open is an opt in that is granted to a site rather than to a brand, and it has an entry condition attached. Deliveroo describes the feature as opening a site on the app the moment the scheduled opening time begins, so that nobody has to remember to do it manually, then states the requirement as “At least 95% availability to request Auto-open” and directs the partner to submit a request in Partner Hub. Source: help.deliveroo.com.
Read the requirement as an amplifier rather than a hurdle. A site that has been reliable qualifies for the feature that keeps it reliable. A site that has had a bad quarter does not, so it keeps depending on a human acknowledgement every single shift, and every missed acknowledgement pushes its availability further from the threshold it needs. The estate does not drift apart at random, it drifts apart in a direction.
There is a second condition that catches even the qualified sites. Deliveroo states that “When you have a Day Off scheduled, your business won’t auto-open on the app.” Source: help.deliveroo.com. So a site with Auto-open enabled and a forgotten day off in its calendar behaves exactly like a site without the feature at all, on that day only, which is close to undiagnosable from head office.
Deliveroo records whether a site runs with a tablet at all, and that changes how it fails.
The Site API carries a field named tabletless, described as “Indicates whether the site operates without a tablet device (ROM)”. Source: api-docs.deliveroo.com. That single boolean divides an estate into two populations with different failure modes.
A site with a tablet has a second, independent switch in the building. Deliveroo confirms it while describing the bulk tool: “a store can still be manually opened or closed using the Deliveroo tablet”. So a head office action taken in Hub can be undone in the branch, and a branch action can be undone in Hub, with no conversation between the two.
A tabletless site cannot be closed by somebody in the kitchen and cannot be closed by a flat battery either. It also cannot be reopened by the fastest route available to its neighbours. The same brand therefore has two different recovery procedures running in parallel, and the correct one depends on a field most operators have never seen.
Deliveroo adds a third surface warning for the web route, telling partners never to close the browser window without closing the restaurant first, and noting that the restaurant will not automatically close if the browser is closed. A site left open in a browser nobody is watching is a site accumulating rejections.
Who on your team can see the Deliveroo Site Status tab, and who cannot?
Permission decides it, and Deliveroo names the roles. The same help article states that “Hub users with the Admin, Admin (limited), Manager, or Manager (limited) role can access the Site Status feature from the “Settings” page in Hub.” Anyone outside those four roles does not get the screen.
For a franchise that is the whole story in one sentence. If the franchisee holds the Hub account for their own sites and the brand holds a separate account for company operated ones, then no single login covers the estate, and the person asking why three branches are dark is looking at a portal that cannot show them.
Menu access is scoped the same way. A site whose account lacks Menu Manager access cannot be edited from the surface everyone assumes is universal, which we cover separately in Deliveroo menu price mismatches. The pattern to take away is that on Deliveroo the answer to “why can that branch do it and this one cannot” is usually a role rather than a fault.
Why can a Forced Closure sit on one Deliveroo site while the rest of the estate trades?
Because it is applied to a site by Deliveroo and cannot be lifted from the partner side at all. The changelog announcing it states that the tool “can only be enacted by Deliveroo”, that a partner wishing to open during an active Forced Closure has to call Partner Support, and that “the Partner will not be able to open the site from their side”. It appears in the list of closed periods with "reason": "FORCED_CLOSURE", and an integration that tries to remove it receives an HTTP 400 with the message “This closed period can only be updated by Deliveroo.” Source: api-docs.deliveroo.com.
One site in that state produces exactly the symptom in this page’s title, and it is the version of the symptom that no amount of work in the branch will change. The same is true one level up in marketing, where Deliveroo assesses access to Marketer against operational criteria and states the outcome per site, referring to “Sites with either ‘Action’ or ‘Improve’ Value Scores” receiving limitations. Source: help.deliveroo.com.
So a brand can simultaneously hold a site trading normally, a site closed by Deliveroo, and a site trading but excluded from offers, all under one name.
How should a chain read the difference between two Deliveroo sites?
Compare the two sites at the same minute rather than comparing either against the brand’s intention. Take the dark site and the working one, and walk the same four questions in order: what does the schedule for that site say for that date, is there a day off or vacation mode against it, is Auto-open enabled on it, and is there a closed period with a reason attached. Those four resolve most splits without a support ticket.
The market numbers say why the answer is worth having quickly. A UAE Deliveroo listing gave up 2.28 percent of its own published trading hours in July 2026 and the typical interruption ran 3 hours 10 minutes, against 0.55 percent and 2 hours 03 minutes for the platform in Kuwait. One brand trading in both markets carries both profiles at once. Because those hours are a per site setting and every mechanism above is a per site state, the only record that compares branches honestly is one built from outside, site by site, against each site’s own published hours, which is what Kitchain (kitchain.co) collects across a Deliveroo estate.