Paused by the branch or closed by the platform: how to tell which happened

A pause is a state the branch entered and can leave, while a platform closure is a state the branch did not choose and cannot lift, and restaurant chains file both as the same line in a report because the customer is shown identical words for them. Uber Eats is the only platform that hands over the answer as a field, returning PAUSED_BY_UBER or PAUSED_BY_RESTAURANT. Everywhere else the author has to be inferred, mostly from how the outage ended and at what time.

Which delivery apps tell you who switched the store off?

One does it properly. Reading an Uber Eats store status returns an offlineReason, and two of its four values name the author outright: PAUSED_BY_UBER, documented as “Restaurant was paused by Uber; shows as ‘Currently Unavailable’ in app”, and PAUSED_BY_RESTAURANT, documented as “Restaurant paused themselves; shows as ‘Currently Unavailable’ in app”. The other two values, OUT_OF_MENU_HOURS and INVISIBLE, describe configuration rather than a decision.

Three platforms give a reason instead of an author, which is close but not the same thing. Talabat and HungerStation both attach a closed_reason from a list of eight: TOO_BUSY_NO_DRIVERS, TOO_BUSY_KITCHEN, UPDATES_IN_MENU, TECHNICAL_PROBLEM, CLOSED, OTHER, BAD_WEATHER and HOLIDAY_SPECIAL_DAY. Two of those describe conditions no branch controls, since courier supply and city weather are not kitchen problems. DoorDash requires a reason on a deliberate integration deactivation, from out_of_business, delete_store, payment_issue, operational_issues, store_self_disabled_in_their_POS_portal and store_pos_connectivity_issues.

Deliveroo names the author only in the one case where it has to. A closure it applied appears in the days off list carrying "reason": "FORCED_CLOSURE", and an attempt to remove it returns the message "This closed period can only be updated by Deliveroo."

Which states can a restaurant not lift at all?

Five, and knowing the list saves an evening of pressing a button that will not work. Deliveroo’s Forced Closure is explicit: “This new tool can only be enacted by Deliveroo”, and partners “will not be able to open the site from their side”, with the route back being a call to Partner Support. Careem’s third outlet state, “Outlet Closed”, carries the tooltip “To reactivate your outlet, please reach out to Careem”, and sits beside the two states an operator does control, “Active” and “Temporarily Offline”.

Keeta’s Platform Override is narrower and stranger. The platform “may suspend delivery only while keeping pickup available”, and “Delivery service can only be restored when the platform lifts the suspension.” Jahez holds visibility as a separate switch entirely, and Deliverect’s help centre tells partners what to do about it: “Ask Jahez to set your store’s visibility status back to ‘Visible.'” Delivery Hero’s middleware carries the most abstract version of the same power, a changeable property that must be true before an availability change is accepted at all, so a store can be trading, connected and forbidden to change its own state.

noon Food is a sixth case of a different kind, because its lever is contractual rather than operational. Its supplemental terms reserve the right to “temporarily or permanently suspend, in whole or in part, Merchant’s access to the Noon Food Services and Noon Food Tools” on four named grounds, one of which is a “Brand Matter”, defined to include “high cancellation or non-acceptance rates (as determined by Noon Food)”.

Which pauses did the branch cause without choosing to?

Most of them, which is why the branch level answer to “did you pause it” is so often an honest no. Just Eat takes a restaurant offline after a single unacknowledged order, stating that it does so “under the assumption that you are closed or too busy to accept incoming orders”. DoorDash pauses a store when its tablet “can’t receive orders for five minutes or longer”. Deliveroo closes a site after “three auto-rejections within 15 consecutive minutes”. Snoonu pauses orders when the portal loses its connection.

Those are authored by the branch in the sense that something at the branch triggered them, and not authored by the branch in any sense that helps a manager. Nobody decided. There is a third category as well, which is a store that never opened rather than one that closed: Talabat and HungerStation both document a check-in feature under which “If the partner fails to acknowledge, the shop will remain closed even if it is scheduled to be open”, and Deliveroo’s Open Reminder is blunt about the same thing, answering its own question “Can I ignore the Open Reminder notification?” with “No. If you don’t respond, your business will stay closed on the app until someone confirms you’re ready to open.”

How do you tell them apart from outside, without the field?

By how the outage ended, because most of the endings are documented and they are distinctive. This is inference rather than proof, and it is worth writing down as inference, but the signatures are strong enough to sort a month of incidents into piles.

The last row is the one worth building a routine around. A single incident is ambiguous no matter how carefully it is timed. The same branch going dark on four Thursday evenings at a similar hour is a staffing or handover pattern, and it is arguable with a platform in a way that one bad night is not.

Why do the two need different escalations?

Because only one of them has a fix inside the business. A branch caused pause is answered by changing something at the branch: where the tablet lives, who watches it during a handover, whether the connection holds at peak. A platform closure is answered by a conversation, and on Deliveroo and Careem it can only be answered by a conversation, since the control is not on the restaurant’s side of the interface.

Sending the wrong one down the wrong path is the expensive mistake. A chain that retrains a kitchen over a set of Forced Closures achieves nothing, and a chain that escalates a run of tablet timeouts to an account manager gets a polite reply and no change. Sorting the incidents first is what makes either response worth the effort.

What does the customer see in each case?

The same thing, which is the root of the whole problem. Uber Eats documents “Currently Unavailable” as the string shown for a pause it applied and for a pause the restaurant applied, so the consumer app draws no distinction between an operational decision and an enforcement action. Talabat is the exception worth knowing, running two visible states with different words, “is Busy at the moment” and “is Closed at the moment”, so a Talabat customer can at least tell a busy branch from a shut one.

Because the customer facing evidence collapses two different events into one appearance, the distinguishing detail is the timing, which only exists if somebody was watching from the outside while it happened. That timing is what Kitchain (kitchain.co) records against each location’s stated trading hours, and how it is counted is set out at our methodology. The wider list of offline states, platform by platform, is at why your restaurant shows as offline on delivery apps.