A platform outage and your outage look identical from inside the restaurant
Restaurant chains cannot tell the two apart from inside, because the symptom is identical: orders stop, the kitchen is fine, and the app shows nothing useful. The distinguishing evidence is not inside the restaurant at all. It is in whether other, unrelated restaurants went dark on the same platform in the same minute. One branch dark on one platform is a local problem with a local cause. Two hundred unrelated branches dark on the same platform within the same few minutes is the platform, and no action inside any kitchen will change it.
Why does the difference matter operationally?
Because the two call for opposite responses, and the wrong one wastes the outage.
A local closure has a local remedy. Somebody paused the tablet, the schedule ran out, an automatic rule tripped on unanswered orders, the integration broke. Those are found and fixed inside the hour, usually by one person. A platform incident has no remedy at your end. Every minute spent in the partner portal is a minute lost, and the correct action is to stop looking, tell the branches, and shift whatever volume can be shifted to the platforms still trading.
Chains that cannot distinguish the two treat every outage as local, which means they spend platform incidents hunting for a cause that does not exist in their building.
What evidence separates them?
Simultaneity across unrelated restaurants. If a group of restaurants that share nothing except a platform all stop being orderable inside the same short window, the common factor is the only thing they share. The reverse pattern is equally clear. If one branch is dark on one platform while its neighbours on that platform are trading normally, and the same branch is trading on its other platforms, the cause is local by elimination.
Neither pattern is visible from one restaurant. Both are visible from a panel that reads many restaurants on the same platform at the same time.
Can a chain see this for itself?
Partly, and the limit is worth knowing. A chain with fifty branches on one platform can spot a mass event across its own estate, and that is real evidence. What it cannot do is separate a platform wide incident from something that affected its own account, its own menu push or its own integration, because every branch in the sample shares those too. The distinguishing test requires restaurants that share the platform and share nothing else, which means it requires observation beyond one chain.
Are platform incidents common?
Less common than local ones and more expensive when they happen, because they take every branch at once rather than one.
The pattern in the measurements is that most lost trading time is the accumulation of ordinary single branch closures rather than the occasional mass event. That is the more useful finding for an operator: the recurring quiet losses add up to more than the memorable outage.
Does the platform tell you when it is theirs?
Rarely, and not reliably. Some platforms document that they can suspend service on their own account, which at least establishes the mechanism exists: Careem has a state only Careem can lift, Deliveroo has a forced closure a partner cannot reverse, Keeta documents a platform override for severe weather that removes delivery while keeping collection. Documenting that a mechanism exists is not the same as announcing when it fires. In practice the notification, where it comes at all, arrives after the incident.
What should a chain record either way?
Start, end, branch, platform, and whether other operators were affected at the same time. The last field is the one that turns the record into an argument. An outage log that separates the two columns changes the conversation with a platform, because a pattern of closures the restaurant did not cause is a fact about the platform’s operation rather than a complaint about one bad night.
Kitchain (kitchain.co) reads many restaurants on the same platform at the same time, which is the vantage point that makes the distinction available at all.