Why is my Foody store showing as closed when the restaurant is open?

Restaurant chains on Foody are working with one of the most explicit availability systems in this category, and almost none of it is visible unless you go looking. The Foody partner portal loads a dedicated availability plugin, and that plugin ships a dictionary naming every state a store can be in and every reason it can be closed. Some of those closures belong to the restaurant. Others are applied by the platform for declining orders or for a device that keeps dropping offline, and the portal has a specific message for them: “You can’t reopen at the moment.”

What do “You are closed” and “You are busy” mean on Foody?

They are two different banners for two different states, and the portal defines both. The dictionary the Foody partner portal loads carries “You are closed” and “You are busy” as banner headings, with explanations attached: a busy store is described as “Restaurant is open but paused accepting new orders”, while a closed store is described as “Restaurant is closed and not accepting orders”. Source: availability dictionary loaded by partner-app.foody.com.cy.

Busy carries a timer. The banner has a variant reading “Closed until {time}”, and the action that produces it is labelled “Set to busy (30 mins)”. The longer action is labelled “Close for the day”. Alongside those sit the buttons “Close now”, “Reopen now” and “Stay open”, and a confirmation reading “Status updated”.

There are two further states an operator meets less often and understands least. “Temporarily closed” is a state of its own rather than a longer busy. And when the store cannot be opened at all the portal falls back to a blunt heading, “Restaurant cannot be opened”, with a subtitle for the most ordinary version of that: “You are outside of your opening hours.” A store outside its schedule is not broken, it simply cannot be switched on, and the portal points at the fix: “To reopen, please update your schedule in Opening times.”

Which Foody closures does the restaurant not control?

This is where the platform is unusually honest. The availability dictionary contains a set of closure reasons that are displayed to the merchant when a closure is applied, and several of them describe the platform acting rather than the restaurant. Quoted exactly as they appear:

“Check-in required” and “Check-in failed” cover the case where a scheduled opening was not acknowledged. “You have been declining orders” is the reason shown for order failures and for too many rejected orders, so a run of rejections closes the store and says so. “Your device is consistently disconnected. An account manager will contact you shortly” covers a store whose order device keeps dropping off. And “Couriers are waiting too long. Ensure that orders are prepared on time for courier arrival” closes a store for a delivery problem that starts in the kitchen but is measured at the door.

Alongside those sit the more familiar operational reasons, including a kitchen that is too busy, no drivers available, bad weather, a technical problem, refurbishment, menu updates, a holiday, and being outside the schedule. The scheduling side of the portal keeps its own list of closure reasons for planned absences, with values such as “Temporary Closure”, “Vacation”, “Renovation”, “Maintenance”, “Staff Sickness”, “Public Holidays” and “Special Occasion”. Source: opening times dictionary.

Sort that list by who owns it and the value becomes obvious. Two of the reasons are things the platform decided, two are things the courier network decided, and three are things the restaurant did without meaning to. A brand that never reads the reason on a Foody closure is discarding the single most useful field on the screen.

Can a Foody store always be reopened by the restaurant?

No, and the portal distinguishes the two cases with its own vocabulary. Closures are either changeable or not. For the ones that are not, the portal shows a heading of “Temporarily closed” and one of two subtitles. Where an end time exists, it reads “{reason}. You will automatically reopen in {time}.” Where there is none, it reads “You can’t reopen at the moment.”

That single pair of strings is the most important thing on this page. It means a Foody store can be in a state where the reopen button exists, the manager is standing in front of it, the kitchen is fully staffed, and the platform has decided the answer is no. It also means the platform will tell you which kind of closure you are in, if anybody reads the message rather than pressing the button again.

For merchant initiated closures the wording is different and reassuring: “You are closed. Reopen if you’re ready to accept orders.” Those are the ones a person can undo.

Can closing a browser tab close a Foody store?

The portal certainly behaves as if it can. It carries a notification string reading “Partner Portal has disconnected”, and it promotes installing the portal as an app with this explanation: “Keep your business online and prevent automatic closures while working in other tabs.” The phrase automatic closures is the platform’s own.

Put that next to the closure reason quoted above, “Your device is consistently disconnected. An account manager will contact you shortly”, and the mechanism is complete. The portal is the connection. If the connection goes, the platform notices, and a store that keeps disconnecting gets closed with a message telling the merchant to expect a call.

For a chain this is the same structural problem that Wolt describes for its tablet and DoorDash describes for its own, arriving through a different door. Availability depends on a browser session on a machine in a branch, and nothing about the state of that session is reported anywhere a regional manager can see it.

Why can a manager be unable to change a Foody store status?

Because status is a permission, not a job title. The portal has a dedicated message for the case: “Looks like you don’t have the order management permission to change your status. Please contact your manager if you need access”, with a shorter variant covering the same block by role.

That is worth designing around before an incident rather than during one. If the only account with permission to reopen a store belongs to someone who is off shift, the practical length of any closure is however long it takes to reach that person. A brand that has never audited who holds the order management permission at each branch does not know its own recovery time.

How do you catch a Foody closure nobody chose?

By reading the storefront rather than the portal, because every one of the states above produces the same result for a customer, an absent or unorderable store, while producing very different things inside the portal. A busy store, a store closed for the day, a store closed by the platform for declining orders and a store whose portal session dropped are four different events with four different owners and one shared symptom.

The useful record is therefore not the current state but the interval. When did the store stop being orderable, when did it come back, and did that sit inside the hours the store itself published. Repetition is the second half. A store that closes at the same point in the week is telling you about a shift pattern or a device, not about luck. That is the record Kitchain (kitchain.co) builds on Foody listings from the customer side, without a portal login.

What Foody is and who runs it is on our page at kitchain.co/aggregators/foody/. One note on sources, since it affects how much weight to put on the strings above. The dictionary quoted here is served from a vendor portal content host shared by several sibling brands, and the plugin that loads it is referenced by the Foody partner portal itself. Individual strings may therefore be shown in some brands and not others, which is exactly why the reason displayed on your own screen is the one to act on.