Why is my Uber Eats store showing as paused when the restaurant is open?

An Uber Eats store can be paused while the kitchen is working normally, and restaurant operators often discover it only when a customer says the app shows the restaurant as unavailable. Uber does not use the word closed for this. Its API defines two writeable states, ONLINE and PAUSED, and when a store is read back as OFFLINE it carries a reason that names who did it: PAUSED_BY_UBER or PAUSED_BY_RESTAURANT. Uber also pauses stores on its own after periods of inactivity, and lifts that pause at 6:00am the following day.

What is the difference between PAUSED_BY_UBER and PAUSED_BY_RESTAURANT?

Authorship, and Uber is the only platform in this category that hands it over as a field. Reading a store’s status returns an offlineReason, and two of its values name the party that acted: 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”. Source: developer.uber.com.

That naming is worth more than it appears, because the two conditions have nothing in common except their effect on a customer. One is a decision the business made and can defend. The other is a decision made about the business, for the reasons set out further down this page, and a chain that cannot tell them apart is arguing about its own operations with the wrong evidence in front of it. The field carries two further values that are not pauses at all, and how an estate sorts across all four is covered on some of your branches are offline on Uber Eats.

The customer sees the same three words in every case. Uber documents the customer facing string as “Currently Unavailable” for both a pause it applied and a pause the restaurant applied, so nothing on the consumer app distinguishes an operational decision from an enforcement action.

The write side is narrower than the read side, and that gap is the whole shape of the platform. A brand can set two values. It reads back four, so two of the conditions a store can be in are ones the brand did not create and cannot remove with the control it has. What each of the two writes does, and why an end time belongs on every pause a restaurant applies to itself, is covered on how to get Uber Eats to put your restaurant back online.

Why does Uber Eats pause a store automatically?

Because it reads inactivity as a store that cannot fulfil orders. Uber’s help centre states the principle in one line: “We may pause your orders when we detect a longer period of inactivity.” It then lists what counts, and the three triggers are “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.

Read the third trigger slowly, because it is the one that produces the symptom in this page’s title in reverse. A store that was physically shut while its Uber Eats hours said open gets paused, and the pause outlives the reason for it. The branch opens the next morning into a state that was created by yesterday evening.

The first trigger is the one that catches multi site brands during a rush. Orders go unaccepted for the same mundane reasons everywhere: a tablet in the back, a shift change, a screen nobody was watching for ten minutes. Uber does not require a decision from anyone to pause the store, and it does not require anyone to have rejected anything on purpose.

None of these triggers announces itself to head office. The pause happens at store level, and the only place the reason is expressed in a machine readable form is the API field described above, which a brand only sees if it is integrated and reading it.

Does an Uber Eats store unpause itself?

Yes, and the rule is published with a time of day in it: “If you don’t manually unpause orders, they will unpause automatically the next day at 6:00am.” Source: help.uber.com.

That single rule produces a shape visible in Uber Eats records and almost nowhere else. Pauses here cluster on one end time rather than spreading across the clock, because every pause nobody attended is finished by the same mechanism at the same minute. An end time of 06:00 is therefore not a neutral detail about an incident. It is a statement that no person took part in ending it, and it is the closest thing this platform offers to an admission that a store went dark unwatched.

The rule also quietly changes what the morning means. A store that reopens at six has been reset rather than repaired, and whatever paused it in the first place has not been looked at by anyone. Uber restores the listing. It does not restore the tablet, the connection or the shift habit that produced the pause, and none of those announce that they are still broken.

Can a POS or tablet problem pause an Uber Eats store?

Yes, and Uber’s integration guidance treats it as the expected behaviour rather than as a fault. The store integration documentation 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.

Combine that with the automatic pause rule above and a chain has two independent paths from one technical fault to a dark listing. The integration can take the store offline deliberately because it knows it cannot deliver orders. Or the integration can fail silently, orders go unaccepted, and Uber pauses the store for it. Both end with a working kitchen and a store the customer cannot order from, and they are recorded differently.

This is why the offlineReason field is worth reading rather than just the status. A store that is OFFLINE with PAUSED_BY_RESTAURANT after an integration fault looks, in any internal report, exactly like a store somebody paused on purpose.

How do you spot an Uber Eats pause you did not choose?

Not from the pause itself, because nothing about it is addressed to the brand. The pause happens at one store, the notification lands on one device, the customer sees three neutral words, and the reason lives in an API field that only an integrated system reads.

The signals worth watching are duration and repetition. A pause that lasts until exactly 6:00am was almost certainly automatic and unattended, because a human would have lifted it sooner. A store that pauses on several evenings at a similar hour has a process problem at that shift rather than a run of bad luck. Neither pattern is visible in a dashboard that reports the current state, which is why the useful record is one built from outside, checking whether each store is orderable against the hours it published, and that is what Kitchain (kitchain.co) does on Uber Eats storefronts.

Background on the platform itself is at kitchain.co/aggregators/uber-eats/. Stores that also sell on platforms without an automatic lift carry a different cost profile, because there the outage runs until a person acts rather than until the next morning. What delivery downtime costs a restaurant sets out how to put hours against both shapes.