Some of your branches are offline on EatEasy and the rest are fine
Restaurant chains asking why part of an EatEasy estate is dark have almost nothing published to read. EatEasy runs no merchant help centre, no developer portal and no partner terms, and the one public instruction that names its back office is written by an integrator. What can be established is that the platform is organised around individual restaurants and their branches, with hours, item availability and its own delivery staff attached at that level. Nothing in the published material describes a brand wide switch, so branches are configured and go dark one at a time.
Where does EatEasy keep the settings that make one branch different from another?
Inside a back office that lives on a different domain from the consumer brand. The integrator Deliverect sends partners to manage.eateasily.com, tells them to pick the sidebar entry it calls “Restaurants Preview”, and locates the restaurant identifier beside a heading it names “Restaurant Basic Info”. Source: help.deliverect.com. The brand name and the login host are not the same domain, which is why the portal is so hard to find in the first place, and for an estate it has a second effect: the people who know that address are the people who were in the room during an integration project, not the people running the branches today.
On 3 September 2026 that login host served its front end script without authentication, and the script names the actions the interface calls. That is our reading of public code rather than a statement by EatEasy. What the names establish is scope rather than behaviour. The restaurant profile is saved against a location identifier, the time information and the delivery time information are edited and saved separately, and a branch list view sits nested underneath a restaurant. In other words the object that holds trading hours on this platform is a location, and a brand is a folder above it.
That single fact is enough to explain an uneven estate without any further mechanism. Hours entered for four branches and not the fifth produce a fifth branch that is closed by its own schedule, every day, until somebody edits that record.
Why is an EatEasy branch connected by a person rather than by a console?
Because no self service integration appears to exist, and the one published instruction finishes by handing the job to a named individual. Deliverect asks the partner to pass the identifier to their contact at Deliverect, who then carries the integration forward.
For a chain that sentence is the reason branches diverge on connection quality. Locations joined during one project were mapped together by one person on one day. A branch opened eight months later went through the same queue separately, possibly with a different contact, possibly with a different menu attached. Nobody re runs the first mapping when the second happens, so an estate accumulates differences that nothing audits.
Two integrators carry this platform, and neither has published anything about how a store on it is switched off or brought back, which we document with the references separately. For an estate the reading is narrow and worth being strict about. A middleware dashboard showing forty EatEasy branches as connected is reporting on its own connection, not on whether those forty branches are selling, and the two diverge silently.
Deliverect covers this for its channels generally, saying only that “Some channels inform Deliverect when a store closure is triggered from their platform.” That is a qualified statement about an unnamed subset, and EatEasy is nowhere in the list of channels it does name.
An EatEasy branch can be open, listed and unable to sell anything.
The item layer is separate from the location layer and is also held per restaurant. Among the named actions in the back office script is one for setting a restaurant food item available, taking a time related parameter alongside the item identifier, and bound in the same file to an on and off control in the interface. That is our reading of the code and not an EatEasy statement, and it establishes that item availability exists as a control rather than what a customer is shown when it is used.
Nothing in the named controls resembles a store level busy, pause or snooze action. On what can be seen, a branch here stops selling for one of two reasons, its timetable or its item list, and both belong to that location alone.
Those two are not the same event and a group should never file them together. A timetable fault fires and clears on a clock, so it recurs at the same hour daily until somebody edits the record. An emptied item list leaves the branch present with nothing worth buying, which a customer reads as a kitchen that has run out. Log both as unavailable and neither can be explained afterwards.
Why can one EatEasy branch lose a district while the branch beside it keeps trading?
Because the platform carries its own delivery layer alongside the restaurant layer. The back office script names branch lists, delivery staff records, dispatch actions against individual orders and an action named for own delivery, which reads as a platform running its own logistics rather than only listing restaurants. That is our inference from the naming rather than a statement by EatEasy.
Where a platform delivers with its own people, availability stops being purely a property of the kitchen and becomes partly a property of the map around it. Courier supply is thicker in some districts than others and thinner at some hours than others, and neither variable belongs to the restaurant or appears in any of its systems. A branch can be configured correctly, stocked fully and still sell nothing for an hour because of the second variable.
For an estate this produces the pattern in the title with no fault anywhere. The branch in a district with thin courier coverage goes quiet at the same hour every week. The branch two kilometres away does not. Neither branch did anything, and no report inside the business separates the two cases.
What does the EatEasy approval queue do to a change made at one branch?
It puts it in a line. Among the named back office actions are ones for accepting and rejecting approvals and for counting pending change requests, which indicates a moderation step between a partner making a change and the change taking effect. Again, this is our reading of the naming rather than a documented EatEasy workflow, and we are not going to state a review time because none is published.
The consequence for a chain is timing rather than content. A trading hours change submitted for six branches on the same afternoon does not necessarily land for all six at the same moment, so an estate can be briefly inconsistent for reasons that are entirely procedural. A brand that treats a change as done at the moment it was saved will misread the gap as an outage.
One further warning applies to anyone tempted to fix a dark branch by reconnecting it, since a republish carries a documented side effect on the catalogue and is covered on our EatEasy menu page. For an estate the risk compounds, because a republish aimed at one dark branch is usually run from a template held for the brand, and the branch that had local pricing loses it while the others look untouched.
What can a UAE chain actually compare between two EatEasy branches?
The storefront, and nothing else, because that is the whole of what this platform exposes. Nobody publishes a status interface here, nobody publishes a set of words for what a closed store is called, no integrator claims to mirror a closure made on the platform side, and there is no partner document a brand could cite in an argument. What does exist is the consumer listing, addressable per city under eateasily.com, and that is where a branch by branch reading has to be taken.
Run the same test at the same minute on both branches. At an address the dark branch should serve, can an order be placed. At an address the working branch serves, can an order be placed. Do those two answers match the hours each branch published for that day. Three separate faults produce the same negative answer, an hours record, an emptied item list and a district with no courier free, and separating them takes a per branch history rather than a single look, which is the record Kitchain (kitchain.co) keeps on EatEasy listings.
Kitchain publishes no downtime figures for EatEasy, so no number on this page describes it. Ownership and markets are on our EatEasy platform page.