Why is my HungerStation store showing as closed when the branch is open?

Restaurant chains on HungerStation lose more hours per incident than on any other platform we measure, because a branch here goes dark rarely and then stays dark. Even with the persistently dead listings taken out of it, an incident here still runs to most of a working shift rather than a lull between orders. On HungerStation we recorded 2,295 offline incidents in July 2026 with a mean length of 12 hours 24 minutes, and 5 hours once those listings are set aside. The same measurement across our UAE panel, on platforms with no HungerStation in them, gives 2 hours 18 minutes. HungerStation documents five vendor states and eight closure reasons, and three of the mechanisms that trigger them sit outside the restaurant entirely.

The timing is as distinctive as the length. Across that panel, 81 percent of unexpected offline incidents began between 22:00 and 02:00 local time, with 731 starting at 23:00 and 705 at midnight. That is the end of the late Saudi dinner trade, and it is the hour at which the person who could reopen the branch goes home. Source: kitchain.co/ksa-delivery-downtime-report.

What makes a HungerStation store show as closed to customers?

HungerStation calls the feature “Outlet Management” and documents four values that can be written to a vendor’s status. CLOSED_TODAY means “vendor will be closed till the end of the day”. CLOSED_UNTIL means “vendor will be closed till the date specified in closed_until field”. OPEN means “open closed vendor if it’s within opening hours according to schedule”. CHECKIN is used “to acknowledge required check in”. Source: developer.hungerstation.com.

Reading a vendor’s status returns a fifth value that cannot be written, and it is the one that hurts. CLOSED is documented as “the vendor was closed without end date” (developer.hungerstation.com/api-specifications). A branch in that state has nothing scheduled to bring it back. It is not waiting for midnight and it is not waiting for a timestamp. It is waiting for a person.

One vocabulary warning before anything else. HungerStation uses the phrase “busy mode” to mean temporary closure, not longer preparation times. Its own overview reads: “Flexible Control: Manage opening hours, temporary closures (busy mode), and required check-ins before opening the outlet for customers, adapting to operational needs.” Source: developer.hungerstation.com. On Deliveroo busy mode keeps you selling. On HungerStation the same two words mean the branch is off.

HungerStation also calls its back office three different names across its own materials, which is why searching for the right article so often fails. The three names, and what they cost an operator trying to trace a change, are set out on our page on HungerStation menu price mismatches.

What do the eight HungerStation closure reason codes mean?

Every closed vendor carries a reason, and HungerStation publishes the whole list: TOO_BUSY_NO_DRIVERS, TOO_BUSY_KITCHEN, UPDATES_IN_MENU, TECHNICAL_PROBLEM, CLOSED, OTHER, BAD_WEATHER and HOLIDAY_SPECIAL_DAY. The field is described as “The reason why the vendor had been closed. Will be omitted if the vendor status is OPEN”. Source: developer.hungerstation.com/api-specifications.

Sort those eight by who owns them and the picture changes. Two are the restaurant’s own decision, TOO_BUSY_KITCHEN and UPDATES_IN_MENU. Two belong to the platform and the weather, TOO_BUSY_NO_DRIVERS and BAD_WEATHER, and a branch closed under either of those has done nothing wrong and can do nothing about it. One, TECHNICAL_PROBLEM, belongs to whatever software sits between the restaurant and the platform. The remaining three carry no diagnostic information at all.

That distribution is the case for measuring from outside. A head office reading its own point of sale sees a normal service in every one of the eight scenarios, because in six of them nothing happened inside the restaurant.

Can a POS integration failure close a HungerStation store?

Yes, and the group platform documents several distinct ways it happens. HungerStation identifies itself as part of Delivery Hero Group in its own vendor privacy statement, and the Delivery Hero integration documentation lists “Hungerstation (Saudi Arabia)” among the platforms it serves. That documentation states: “Integration Middleware API allows Vendors to state if they are open or closed. If closed, the vendor will be marked as offline on the Delivery Hero platform and customers won’t be able to place orders.” Source: developers.deliveryhero.com.

The same page describes the platform switching an integration off rather than the restaurant doing it: “The integration might get disabled by Delivery Hero whenever there is a technical issue with the plugin and provided contact is not responding. The integration will be re-activated once the issue is fixed by plugin maintainer.” And more broadly: “Some features of an integration or even the whole integration might get disabled whenever certain article of the implementation contract ain’t fulfilled.”

There is a third mechanism that surprises everyone who meets it. The middleware availability endpoint carries a changeable property, and the documentation instructs integrators that it “should first be checked which kind of availability changes are allowed by making a GET request to this endpoint and verifying that the changeable property is true otherwise the request will be unsuccessful.” Source: Delivery Hero Integration Middleware OpenAPI. In other words, the right to change your own availability is itself a permission, and it can be off.

Finally, HungerStation operates a check-in rule of its own: “This feature enables you to confirm the upcoming opening of your shop up to 30 minutes before its scheduled opening hours. If the you fail to acknowledge, the shop will remain closed even if it is scheduled to be open.” It is disabled unless you ask for it: “By default, this feature is disabled and does not require a check-in status to be sent. To activate the check-in flow, please contact your account manager.”

Why does a HungerStation closure last 12 hours and a UAE one last two?

Start with what the documentation does not say. We searched HungerStation’s developer portal and the Delivery Hero specifications for a statement that a closed branch is brought back automatically, and there is none. CLOSED_TODAY is tied to the end of the day and CLOSED_UNTIL to a timestamp the restaurant supplied, but the platform nowhere promises to reopen anybody. The read only value CLOSED, defined as having no end date, describes a state with no exit written into it.

Add the three permission facts above. Check-in has to be switched on by an account manager. The right to change availability can be revoked by the changeable flag. Access to the Partner Portal plugins is granted by an account manager rather than by self service. Each of those puts a person from the platform between the restaurant and its own status, and a state with no exit plus a permission held by somebody else is how a 12 hour 24 minute mean gets built.

Then add the clock. Most HungerStation incidents start after 22:00, when the branch that could press the button is closing and the account manager who could grant the permission is off duty. An incident that begins at 23:00 and needs a person is already twelve hours old by the time anybody is available to touch it, which is the whole of a 12 hour 24 minute mean and requires nothing unusual to happen. The 5 hour figure is the same panel with persistently dead listings removed, so it describes incidents on branches that were genuinely trading.

How much trading time do Saudi restaurants lose on HungerStation?

Across the panel, 31,357 trading hours in one month. As a share it is 2.88 percent of stated trading hours, falling to 0.77 percent once the 5.6 percent of listings that were offline for more than 90 percent of July are excluded as most likely delisted. The distance between those two numbers is the real finding. Three quarters of the headline figure comes from a small group of listings that are not really trading at all, and a brand that never audits its own catalogue can carry dead branches on the platform for months while its dashboard reports an availability problem that its working branches do not have.

Separating the dead listings from the live outages needs a record of when each branch was orderable against the hours it published, which is what Kitchain (kitchain.co) collects on HungerStation from the customer side, with no portal login and no POS integration in the path. The full Saudi benchmark, including the incident lengths quoted above, is at kitchain.co/ksa-delivery-downtime-report, and our platform page on HungerStation is at kitchain.co/aggregators/hungerstation/.