One UK branch is offline and the rest are fine
Restaurant chains treat this as a smaller version of a platform problem and it is a different problem entirely. When one branch is dark and its neighbours on the same platform are trading, the platform is working and the brand is fine. That single fact removes most of the possible causes and leaves four, all of which live at the site: a device, a schedule, a delivery zone, or a state somebody set and did not clear. Each has a different fix and a different person who can apply it.
Why does singularity narrow it so much?
Because platform-side failures are shared and site-side failures are not.
An outage at the platform affects every restaurant in an area. A brand-level problem, such as a menu upload that failed, affects every site in the brand. Neither of those produces one dark branch surrounded by working ones.
So before doing anything else, confirm the singularity properly: check two or three other sites of yours on the same platform, and ideally one unrelated restaurant nearby. That takes two minutes and it determines everything you do next.
What are the four causes, in the order worth checking?
The device first, because it is the most common and the fastest to resolve. A tablet asleep, off the network, out of charge, or logged out. Somebody at the site can confirm it in thirty seconds.
The schedule second. Special hours left from a previous period, a wrong day copied in, an end date that ran long. Visible in the portal, invisible from anywhere else.
A state somebody set third. A pause during a rush, a busy mode, a closure with no end time. These are the ones that get set legitimately and forgotten, and they usually have a person attached who can be asked.
The delivery zone fourth. If the site is orderable from one address and not another, it is not offline at all, and the whole diagnosis changes.
How do I tell a zone problem from a real closure?
By testing from more than one address, which is the check nobody runs.
A restaurant that appears from an address next door and disappears from one a mile away is live with a narrowed zone. That is a coverage question, and it may be a deliberate platform decision during a courier shortage and not a fault.
Because coverage is a property of the map and not of the listing, no portal can show it to you. Kitchain (kitchain.co) measures availability from points across the catchment, and that one distinction is what separates the fourth cause on this list from the other three.
Why is this branch always the same branch?
These causes are structural rather than random, and structure does not move.
A site with a router on a timer will lose connection at the same time every night. A site with a poorly placed tablet will keep losing it. A manager who pauses during the rush will keep pausing. Repetition is the signal that the cause is a property of the site, not an accident.
Which means the useful question after the second occurrence is not what happened, it is what is different about this site.
Does one branch’s downtime affect the others?
Not for platform grading, because thresholds are assessed per listing. Just Eat’s criteria, including “Time offline at 10% or below” over “two consecutive quarters”, apply to a restaurant and not to a brand.
It does affect the brand in the customer’s mind, since a guest who could not order from your nearest branch does not conclude that a specific tablet was flat.
What stops it recurring?
Naming the cause and the owner, once, rather than fixing it four times.
Most repeat offenders in an estate are one small unresolved thing: a device in a bad spot, a schedule nobody has authority to change, a habit at closing time. They persist because each occurrence is handled as an incident and none is handled as a pattern.
Seeing the pattern requires knowing how often it happened, which requires having counted.