Some of your branches are offline on Uber Eats and the rest are fine
Restaurant chains on Uber Eats have something most platforms do not give them, which is a field that says why each store is off and who did it. Reading a store’s status returns an offlineReason, and the four published values separate four completely different problems that all look the same to a customer. That is the fastest route to understanding a split estate here, and it is also the reason a brand without an integration is guessing, because the field lives in the API rather than on any screen a branch manager sees.
Which four offlineReason values does Uber Eats attach to a single store?
Four, and each one belongs to a different owner. Uber documents them as OUT_OF_MENU_HOURS, described as “Restaurant is outside of business hours”, INVISIBLE, described as “Restaurant is not visible in app”, PAUSED_BY_UBER, described as “Restaurant was paused by Uber; shows as ‘Currently Unavailable’ in app”, and PAUSED_BY_RESTAURANT, described as “Restaurant paused themselves; shows as ‘Currently Unavailable’ in app”. Source: developer.uber.com.
Two of those name the party responsible outright. One is a configuration state. One is a visibility state that is not a pause at all. Sorted across an estate, those four categories answer most of what a head office wants to know before anybody makes a phone call.
The customer sees none of it. Uber documents the same customer facing string, “Currently Unavailable”, for a pause it applied and a pause the restaurant applied, so nothing on the consumer app distinguishes an operational decision from an enforcement one. Anybody comparing branches by looking at the app alone is comparing four different problems as if they were one.
The write side is narrower than the read side, accepting ONLINE and PAUSED with a paused_until timestamp and a free text reason. Source: developer.uber.com. Uber publishes no vocabulary for that free text field, which means a brand’s own reasons are only as consistent as the brand makes them.
Why does OUT_OF_MENU_HOURS repeat at the same store every day?
Because it is not an event, it is a setting, and the setting belongs to the menu rather than to the status control. A store returning that value is unavailable for the entirely undramatic reason that its own hours say so, and it will return it again tomorrow at the same time.
For an estate that produces the most durable form of the symptom in this page’s title. A branch whose menu hours were entered once, during onboarding, and never revisited will be dark for part of every trading day, forever, while its neighbours trade normally. Nobody reports it because nothing goes wrong. Orders simply stop arriving at a predictable hour and start again later.
It is also the case that responds worst to the obvious fix. Setting the store online does not change the menu hours, so a manager who unpauses the store and watches it go dark again the following day will conclude the platform is faulty.
The value to take from this is that a per branch availability record with timestamps separates the two shapes immediately. A pause is irregular and follows an event. A menu hours problem is regular and follows a clock.
What does INVISIBLE mean when only part of an estate is missing?
It means a store is absent from the app without being paused, and Uber gives it its own value precisely because it is a different condition. The published description is “Restaurant is not visible in app”, and it sits alongside the two pause reasons rather than inside them.
For a chain that distinction is worth acting on, because the two states have different fixes. A paused store is switched back on. A store that is not visible is not offering the control that would help, and the question becomes why the listing is not being shown rather than why the store is not accepting.
It is also the state that is hardest to detect from the inside. A branch running normally, taking no orders, whose own tooling reports it as online, is the classic version of a listing that has quietly stopped being surfaced. Nothing in the kitchen will report it, and nobody in the branch has a reason to check.
Because the value is returned per store, a brand reading it across an estate can see whether one branch is affected or several. That difference points in opposite directions, since one branch suggests a record about that branch and several suggest something upstream.
Why does the six o’clock lift cost your late trading branches most?
Because the automatic recovery is fixed to a clock rather than to a duration. Uber publishes the rule with a time in it: “If you don’t manually unpause orders, they will unpause automatically the next day at 6:00am.” Source: help.uber.com.
That guarantee is worth the same to every store and costs each of them a different amount. A branch that closes at nine loses whatever was left of one evening. A branch trading until two in the morning loses five hours of its most valuable service. A twenty four hour location loses the entire night. Same rule, same event, three very different bills.
The triggers behind an automatic pause are published too, and none of them scales with the size of a branch. All three describe a device that nobody answered, which is a condition a twelve seat unit and a flagship arrive at by exactly the same route. An estate is therefore not sorted by turnover here, it is sorted by which sites have somebody looking at a screen in the evening, and that is a rota question rather than a technical one.
The habit that removes most of this cost is procedural rather than technical. Every deliberate pause should carry a paused_until value, so that a store comes back when the brand intends rather than when the platform decides.
What does a per store paused_until value do to an estate?
It converts an unbounded state into a bounded one, one store at a time, and it is the only lever a brand actually controls here. Uber documents the field as “The timestamp until which a store will not be accepting new orders”, available on the write that pauses a store.
An estate where every pause carries that value behaves predictably. Every off state ends at a moment somebody chose, so any store still dark past its own timestamp is an exception worth investigating. An estate where pauses are created without it behaves the opposite way, since every off state runs to six in the morning regardless of what was intended.
Integration faults reach the same field from another direction. Uber’s store integration guidance tells 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. So a connectivity problem at one branch is expected to produce a deliberate pause, and whether that pause carries an end time depends on how the integration was written rather than on anything in the branch.
How should a chain read Uber Eats stores against each other?
Read the reason, then the shape, then the clock. Take offlineReason for every store at the same moment and group the estate into the four categories above. Then look at the shape of each store’s history, since a menu hours problem is regular and a pause is not. Then check what time each pause ended, because one that ended at exactly six in the morning was unattended and one that ended earlier was noticed.
That third check is the one that turns an availability report into a management conversation. A store whose pauses consistently run to the automatic lift has nobody watching it in the evening, which is a staffing pattern rather than bad luck, and it is fixable once somebody can point at it.
None of that is visible in a view that shows the current state, and a brand without an integration cannot read the reason field at all. The record that survives is one built from outside, store by store, against the hours each store published, which is what Kitchain (kitchain.co) collects across an Uber Eats estate.