Does Uber Eats tell you when your restaurant goes offline?
Restaurant chains on Uber Eats are handed something rare and left to collect it themselves. Uber records the authorship of every pause in a field called offlineReason, with PAUSED_BY_UBER documented as “Restaurant was paused by Uber” and PAUSED_BY_RESTAURANT documented as “Restaurant paused themselves”. That is the single most useful fact anyone could want during an outage, and it is published as a value returned when a store’s status is requested. Nothing in Uber’s documentation describes it arriving unprompted.
Where does Uber Eats record the fact that it paused your store?
In the read side of the store status endpoint, as one of four values. Uber documents OUT_OF_MENU_HOURS as “Restaurant is outside of business hours”, INVISIBLE as “Restaurant is not visible in app”, and the two pause values above, each of them accompanied by the note that the store “shows as ‘Currently Unavailable’ in app”. Source: developer.uber.com.
Four values is a real taxonomy. It separates a scheduling fault from an enforcement action, and a store that is absent from the app from one that is present but paused. Most platforms in this category collapse all four into a single unavailable state.
The catch is the verb attached to it. This is a status you get, so the field describes the store at the instant of the call and carries no history. A chain polling every fifteen minutes knows the reason accurate to fifteen minutes. A chain not polling at all has a beautifully modelled field it will never see.
Why does the Uber Eats customer string erase the distinction the API keeps?
Because Uber uses one phrase for both cases and documents that it does. The definitions of PAUSED_BY_UBER and PAUSED_BY_RESTAURANT are identical in their consumer facing half, and the write side repeats it, defining PAUSED as “Not accepting orders, show as ‘currently unavailable’ in app”. Source: developer.uber.com.
So the person most likely to notice first, the customer, is given the least informative version. A regular guest who opens the app and sees a favourite restaurant marked as currently unavailable cannot distinguish a kitchen taking a breather from a platform enforcement action, and neither can a manager relying on a customer’s phone call as the alerting mechanism.
That matters because on Uber Eats a customer’s phone call is a very common alerting mechanism. The one place the authorship exists is a machine readable field, the one place the state is broadcast is a consumer screen, and the two carry opposite amounts of information.
Does Uber Eats say anything at the moment the inactivity rule fires?
Uber publishes the rule and does not publish an accompanying message. The help centre states the principle, “We may pause your orders when we detect a longer period of inactivity”, and lists the three triggers: “Multiple orders in a row that go unaccepted”, “Your acceptance time is longer than usual, resulting in customers canceling orders”, and “An order comes in during your operating hours and your store was closed”. Source: help.uber.com.
Every one of those three describes a store that was already not being watched. Orders going unaccepted means nobody answered the device. A slow acceptance time means the same thing more gently. A store that was physically shut during its own opening hours means nobody was there at all.
An alert designed for that situation would have to reach someone who is not in the branch. Uber does not describe one, and the trigger conditions guarantee that whoever was supposed to be looking at the local screen was not looking at it.
What arrives when an Uber Eats store unpauses at six in the morning?
Nothing, and that is the reason these events go unexamined. Uber publishes the recovery rule with a time in it: “If you don’t manually unpause orders, they will unpause automatically the next day at 6:00am.”
Automatic recovery is genuinely valuable, and it is also an evidence shredder. A store paused at half past eight on a Saturday evening is trading normally by breakfast on Sunday, and there is no interruption left for anyone to look at on Monday. The lost revenue appears as a slightly weak Saturday, which is the easiest thing in hospitality to explain away.
The write side offers one habit that helps, and it costs nothing. A pause can carry paused_until, documented as “The timestamp until which a store will not be accepting new orders”, plus a free text reason. A brand that always sets both turns its own deliberate pauses into events with a shape, which makes the remaining shapeless ones easier to spot.
Which Uber Eats offline reason repeats every day until somebody edits a menu?
OUT_OF_MENU_HOURS, and it deserves separating from the rest because it is not an incident at all. Uber defines it as the store being outside of business hours, and those hours belong to the menu rather than to the store. A menu whose hours were entered once and never revisited will make the store unavailable at exactly the same moment every day, indefinitely, with no pause ever having been applied by anybody.
No alert would fire for that even in principle, because from the platform’s point of view nothing went wrong. The configuration is being honoured precisely.
The fourth value has the opposite problem. INVISIBLE is documented in three words, “Restaurant is not visible in app”, and Uber publishes no list of what puts a store into it. An integrated brand that reads that value has been told the store is missing and given no vocabulary to interpret why, which is the one case on this platform where the field arrives without the attribution the other three carry. It is also the value most likely to be mistaken for a pause and escalated to the wrong team.
The same logic covers the integration side. Uber instructs partners to take stores offline “when they are unable to fulfill orders during store hours (e.g. while experiencing connectivity issues or undergoing maintenance)”. Source: developer.uber.com. A store taken down by its own middleware for a connectivity problem is doing what Uber asked, so no rule has been broken and nothing needs announcing.
What should a brand read on Uber Eats when nothing is sent?
Two things, and only one of them requires an integration. If the brand is integrated, read offlineReason rather than the status alone, and record it with a timestamp, because it is the only free attribution any platform in this category hands over. A pause attributed to Uber and a pause attributed to the restaurant belong in different conversations and different escalations.
If the brand is not integrated, read the storefront. Whether each store can be ordered from right now, checked against the hours that store published for today, catches all four of Uber’s reasons as one measurable interval, and it works for the branches that are on somebody else’s franchise agreement and outside the integration entirely. That is what Kitchain (kitchain.co) records on Uber Eats storefronts.
Two patterns are worth naming in advance. A pause that ends at exactly six in the morning was almost certainly automatic and unattended, because a person would have lifted it sooner. A store that goes unavailable at the same minute every day is a menu hours problem rather than an operational one, and it will keep happening until the menu is edited.