How to get Uber Eats to put your restaurant back online
Restaurant operators on Uber Eats have a short answer and an important precondition. The short answer is that the store status accepts a value documented as ONLINE, described as “Accepting new orders”, and writing it returns the store. The precondition is that two of the four reasons Uber gives for a store being offline are not status problems at all, and pressing resume against either of them changes nothing. Uber also lifts unattended pauses on its own, publishing the rule with a time of day in it: orders “will unpause automatically the next day at 6:00am”.
Uber Eats gives one write for the return and it is called ONLINE
The write side of the store status API is deliberately narrow. It accepts ONLINE, documented as “Accepting new orders”, and PAUSED, documented as “Not accepting orders, show as ‘currently unavailable’ in app”. Alongside them sit a paused_until field, described as “The timestamp until which a store will not be accepting new orders”, and a free text reason. Source: developer.uber.com.
Two values in, four values out, and that asymmetry is the design worth understanding. A brand can only ever set two things. What it reads back can describe four different conditions, and only some of them are reversible by the thing it can set.
For a brand without an integration the same action lives in Uber Eats Manager and in the merchant application, and Uber’s help centre frames manual unpausing as the normal expectation, telling merchants what happens “If you don’t manually unpause orders”. So the manual route is available for the automatic pauses too, which is not true on every platform in this category.
Read offlineReason before you unpause, because two values are not status problems
The read endpoint returns an offlineReason, and only two of its four documented values describe a pause. Those two, and what the difference between them says about who acted, are set out on why an Uber Eats store shows as paused while the restaurant is open. The remaining two are the reason this section exists, because a resume pressed against either of them accomplishes nothing whatsoever.
OUT_OF_MENU_HOURS is documented as “Restaurant is outside of business hours”, which makes it a menu configuration fault rather than an availability one. A store in that condition declines to sell at the same hour every day, and the only thing that changes it is an edit to the hours on the menu. A resume against it produces a store that appears to come back and then does not, which a branch experiences as a platform that keeps failing at teatime.
INVISIBLE is documented as “Restaurant is not visible in app”. That is a third kind of absence, because a store can be missing from the app while not being paused, and no status write addresses it. Source: developer.uber.com.
So the first action on this platform is a read, not a write. Half the possible answers send you somewhere other than the control everybody reaches for, and the time spent pressing it anyway is the most commonly wasted half hour on Uber Eats.
6:00am is a backstop, not a recovery
Uber publishes the automatic lift plainly: “If you don’t manually unpause orders, they will unpause automatically the next day at 6:00am.” Source: help.uber.com.
That is genuinely better than platforms where a pause with no end date waits indefinitely for a person, and it is close to worthless for the hours that actually earn money. A pause beginning at 20:30 and lifting at 06:00 has run for nine and a half hours, of which the expensive part is the three or four hours of dinner service inside it. The automatic lift does not shorten the outage that mattered, it only guarantees that the next morning starts clean, and in doing so it removes the evidence that anything happened.
That is why an incident review that relies on the merchant tools finds nothing. By the time anybody looks, the store is online, the status is correct, and the only trace of the evening is a gap in the sales figures that gets attributed to weather.
Set paused_until on the way in so the return does not depend on memory
The single most useful habit on this platform is to attach an end time to every deliberate pause, because paused_until exists precisely for that and nothing else in the API schedules a return. A pause with a timestamp behaves like a scheduled event. A pause without one behaves like a decision somebody has to remember at the end of a shift.
There is no counterpart on the way out. Nothing in the documentation lets a store book itself back online at an arbitrary future moment beyond that field, so the discipline has to happen at the moment of pausing rather than afterwards.
The free text reason deserves the same treatment. It is not validated and it is not shown to customers, which makes it the cheapest available place to record why a store went off and who decided it. A brand that fills it consistently can later separate a pause taken for a kitchen fire from one taken because a delivery was late, and a brand that leaves it empty cannot.
Why an unpaused Uber Eats store can still be absent from the app
Because the pause was a symptom and not a cause, and Uber states the principle behind it in a single line: “We may pause your orders when we detect a longer period of inactivity.” The three triggers it publishes all describe conditions inside the branch, and every one of them is still true the second after a resume.
That is the loop this platform is prone to. A store unpaused onto a tablet nobody is watching gathers the same unaccepted orders and is paused again within the hour, and from head office the sequence reads as a platform that keeps switching a working restaurant off. The check that breaks the loop is confirming somebody in the branch can accept an order before anyone presses resume, and the triggers themselves are listed on why an Uber Eats store shows as paused.
The integration path produces the same loop by a different route. Uber’s guidance 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 brought back while the integration is still failing is a store that will be taken offline again by the system that knows it cannot deliver orders, which is the correct behaviour and a bad outcome.
What should a chain log about an Uber Eats pause it did not choose?
The reason value, the two timestamps and nothing else, because those three fields answer every question that follows. The reason says whether the store or Uber applied it and whether it was a status problem at all. The start time says which service was lost. The end time says whether a human ended it or the platform did.
The end time is the field worth arguing about, because it is the one that says whether the return was performed or merely happened. A store recorded as recovered at 06:00 was recovered by Uber, and filing that as a fix by the operations team hides the actual failure, which was that nobody knew. Kitchain (kitchain.co) records the minute an Uber Eats storefront became orderable to a customer again, which is the version of the end time that neither the branch nor the platform is placed to supply.
Then use the log for the one question that improves anything. Not how many pauses a store had, but how many of them a person ended. That ratio measures the only part a chain can change, and it degrades quietly the moment a branch stops watching, which is exactly when nothing else in the system will say so.