Why is my restaurant showing as offline on delivery apps when I am open?

A restaurant listing can show as offline while the kitchen is open, and restaurant chains running several delivery apps are dealing with six different mechanisms wearing one word. Deliveroo closes a site after three auto rejections in fifteen minutes. Just Eat takes a restaurant offline after one unacknowledged order. DoorDash pauses a store when its tablet has been unreachable for five minutes. Careem has no busy state at all. What differs most is the exit: some of these states expire on a clock, and some wait for a person who does not know they are needed.

What does offline actually mean on each delivery app?

The word is not shared, and neither is the concept underneath it. Uber Eats never uses the word closed here, writing PAUSED and showing customers “Currently Unavailable”. DoorDash calls it a temporary deactivation, “an automatic pause that prevents new orders from coming in”. Keeta calls it “Suspend Store”, Careem “Temporarily Offline”. Talabat has no single word and writes CLOSED_TODAY, CLOSED_UNTIL or a bare CLOSED.

Read the last column before the second. The trigger decides how often you go dark. The exit decides what it costs.

Our restaurant shows as closed on the app but we are open. What is happening?

That sentence, in those words, is how most operators first describe this, and it is worth answering literally before going near causes. The storefront a customer opens and the restaurant you are standing in are two different objects with two different states. Yours says open because the kitchen is running. The platform’s says closed because something set it that way, and the something is often neither a person in your building nor a fault in any system you own.

Which delivery apps switch a restaurant off automatically, and how fast?

The thresholds sit two orders of magnitude apart, and none of them is negotiable at branch level. Just Eat publishes the strictest and states both halves of it in the same answer: “If you fail to acknowledge an order within 5 minutes it will be automatically rejected”, then “If you do miss the order and it is rejected, your restaurant will be taken offline under the assumption that you are closed or too busy to accept incoming orders.” Source: partnerinfo.just-eat.co.uk. One order.

Deliveroo needs a run rather than a single miss, and publishes the rule as a machine readable reason: “When the restaurant was closed because they experienced three auto-rejections within 15 consecutive minutes”, returned as Unable to open restaurant, reason: CLOSED_PERIOD. Source: api-docs.deliveroo.com. Uber Eats states a principle rather than a count, “We may pause your orders when we detect a longer period of inactivity”, and lists “Multiple orders in a row that go unaccepted” first. Source: help.uber.com.

DoorDash is the outlier because it does not wait for an order at all. Its Tablet Heartbeat monitor “automatically pauses your store if your DoorDash Tablet can’t receive orders for five minutes or longer”, with published triggers including a drained battery and “The Order Manager app isn’t open, logged in, or active on the Orders page”. Source: help.doordash.com. Availability there is a property of one device in one branch, minute by minute, all day.

Snoonu has the mildest version of the same idea and puts it on screen in words. Its portal carries the string “No connection to Snoonu. Orders paused” next to “Reconnecting services”, so a network drop pauses orders and announces itself. Source: the portal’s own interface dictionary of the Snoonu Portal.

Which offline states end on their own and which wait for a person?

This split decides the size of the bill, and it does not follow the size of the platform. Just Eat restores the storefront the next day. Uber Eats lifts an automatic pause “automatically the next day at 6:00am”. Snoonu runs a countdown against a busyUntil timestamp and re-reads the branch status when it expires. Careem attaches an end to an offline period, displayed as “Offline until {{ time }}” and “Back online on {{ time }}”.

Keeta goes the other way in writing. Its Suspend Store endpoint states that “Suspended stores remain hidden from customers until manually reactivated”, and nothing puts a timer on that. Talabat’s read endpoint returns a CLOSED value documented as “the vendor was closed without end date”, the same shape of problem. DoorDash has a backstop rather than a recovery: “If no end date is specified in the deactivation request, the store will only be deactivated for two weeks and will automatically reactivate after that period has passed.”

An automatic lift is worth less than it sounds in the evening. A pause that starts at 20:30 and ends at 6:00am ran nine and a half hours, and the expensive part of it was over before midnight. What automatic restoration mainly buys is that nobody investigates it afterwards.

Which offline states can a restaurant not lift at all?

Four platforms publish a state that the partner is locked out of. Deliveroo introduced Forced Closure and wrote that “This new tool can only be enacted by Deliveroo”, adding that a partner “will not be able to open the site from their side” and that an attempt returns the message “This closed period can only be updated by Deliveroo.” Source: api-docs.deliveroo.com. Careem holds the equivalent in a tooltip: “To reactivate your outlet, please reach out to Careem”, attached to its third outlet state, “Outlet Closed”.

Keeta describes a narrower version and it is the strangest state on this page. Under the heading “Platform Override”, Keeta says it “may suspend delivery only while keeping pickup available”, that “The store’s overall status remains Open because pickup is still available”, and that “Delivery service can only be restored when the platform lifts the suspension.” Source: api-docs.mykeeta.com. From outside, that is a listing that looks open and cannot be delivered from. Any check that reads only a top level status will score it as healthy.

Telling these apart from outside is a separate job, set out on paused by the branch or closed by the platform.

Why does the merchant dashboard still say the restaurant is open?

Because most of these states are produced somewhere the dashboard does not look. Deliveroo says plainly of its own web tool that “POS errors don’t appear on the web app yet. If an order fails to transfer to the POS, it won’t show up in the Web app.” Talabat carries TECHNICAL_PROBLEM in its list of eight closure reasons, so an integration fault is a documented cause of a closed vendor rather than an exception. A tablet with a flat battery reports nothing at all to anybody. The question “is our system healthy” and the question “can a customer order right now” have different answers often enough to need separate treatment, which is on storefront status and POS status are not the same thing.

How long do these interruptions actually run?

Long enough to cover a service. In our July 2026 panel, the mean interruption ran 3 hours 08 minutes on Careem Food in the UAE, 3 hours 10 minutes on Deliveroo, 3 hours 34 minutes on Talabat, 2 hours 32 minutes on Keeta and 1 hour 50 minutes on noon Food. In Kuwait the same measurement gave 23 minutes on Snoonu and 10 hours 39 minutes on Jahez. Across the UAE panel, listings lost 1.68 percent of their stated trading hours, an average of 9.5 hours per listing for the month.

Those numbers track the exit column of the table above more closely than anything about the kitchens. Snoonu, whose pause carries its own expiry, produces the shortest interruptions we measure anywhere. Jahez, where no auto-return rule is published, produces the longest. Because the exit rule really governs the gap between a listing going dark and somebody noticing, that gap is what Kitchain (kitchain.co) times from the customer side, against the hours each location told the platform it would trade. How it is counted is set out at our methodology.

These states read from the customer’s side, starting from the words a caller actually used, are on what does “temporarily unavailable” mean on a delivery app.