Does EatEasy tell you when your restaurant goes offline?
Restaurant chains on EatEasy have no published answer to this question, because EatEasy publishes nothing for restaurants at all. There is no merchant help centre, no developer documentation and no partner FAQ. What can be examined is the back office itself, which serves its front end script without a login, and our reading of that script finds one notification shaped mechanism: a pending order counter the browser asks for on a loop. Everything else that sends a message on this platform sends it to customers.
What notification machinery exists in EatEasy’s own public code?
A counter, and it is a pull rather than a push. Our reading of the script served by the back office at manage.eateasily.com finds the interface posting to a pending order count route, which is the pattern a page uses when it wants to keep a badge current while it is open.
Everything about that shape matters here. A polled counter answers the question of how many orders are waiting. It does not answer whether the store is still visible to customers, and it stops answering anything at all the moment the page is closed.
The rest of what our reading finds is control rather than notice. There are routes for editing the storefront, for setting item availability with a time flag, for editing opening times and delivery times, and a set of approval routes covering acceptance and rejection of pending change requests. Those are things a person does. None of them is a channel through which the platform reaches a person.
We did not call any of those routes, and their exact behaviour is an inference from their names and from the interface wiring around them rather than a documented specification.
Who are the EatEasy batch email jobs actually addressed to?
Consumers, on the evidence of the names. Public web archive records for the same host include scheduled job paths for sending a promotional email to all users, for running an email campaign, for expiring loyalty points and for restaurant offer discounts. One further path is named in a way that suggests chasing pending restaurant orders, and reading intent from a path name is a guess rather than a finding, so we are flagging it as one.
The distribution is the point. EatEasy has bulk email infrastructure. In everything visible from outside, that infrastructure is pointed at the customer base and at marketing, which is the same pattern seen on several platforms in this category and is worth naming because operators often assume that a platform capable of emailing them about a campaign is also capable of emailing them about an outage.
The stack underneath is old enough to be worth mentioning as context rather than as criticism. The back office responds with a PHP version from the five series, an Internet Explorer compatibility header and a session cookie carrying a year in its name, which places the design of this interface a long way before push notifications became a normal expectation of a merchant tool.
Does an EatEasy merchant application change the answer?
Not in any way we can verify. A merchant application is published for Android under the EatEasy name, and a mobile application is the natural place for a push notification to arrive. Source: play.google.com.
What we cannot do is claim it alerts on availability, because nothing published says so. There is no feature list from the platform describing an availability warning, no help article explaining what notifications the application raises, and no developer material describing what the platform sends.
The honest position is therefore narrow. A channel that could carry an alert exists on one operating system. Whether it carries this particular alert is undocumented, and an operator should establish that on their own devices rather than assume it, because the assumption is the sort that is only tested during an outage.
Which EatEasy screen would a manager have to be watching, and on what?
The back office, in a browser, on a machine somebody is sitting at. Deliverect, which integrates the platform, names the two screens it needs a merchant to visit, instructing a partner to “Go to https://manage.eateasily.com and log in”, then to “Select the Restaurants Preview option in the sidebar”, where the identifier sits next to a “Restaurant Basic Info” header. Source: help.deliverect.com.
Two things follow for a chain. The back office lives on a second level domain that is not the consumer brand’s, which is why operators looking for it in the obvious place have historically not found it, and a tool nobody can find is a tool nobody is watching.
The second is scale. A single browser session covering every branch is fine for a two site operator and impossible as a monitoring control for a group. There is no email digest, no scheduled report and no subscription described anywhere, so coverage is a function of how long somebody keeps a tab open.
Why does EatEasy running its own couriers widen the gap?
Because it adds a failure mode that produces the same silence. Our reading of the same script finds routes covering the platform’s own delivery operation, including courier records, branch lists and dispatch details, which is consistent with EatEasy fulfilling orders itself rather than relying on the restaurant.
Where a platform runs the logistics, an outlet can stop being orderable for reasons that have nothing to do with the kitchen and everything to do with courier coverage in that area at that hour. On platforms that publish closure reasons, that case has a name. Talabat and HungerStation both carry a code for a closure caused by a lack of drivers.
EatEasy publishes no reason vocabulary at all, so an operator whose store went quiet cannot separate a courier problem from a menu problem from a store somebody switched off. Every cause presents identically, which is the same as saying there is no diagnostic information in the event.
What is the only durable record of an EatEasy outage?
One built from outside, because there is no inside to build it from. The integrator’s general rule is the clearest statement available on whether a closure travels anywhere, and it is deliberately conditional: “Some channels inform Deliverect when a store closure is triggered from their platform. If supported, it will show in your Deliverect Operation Reports as Busy Mode Sync and a log explaining what triggered the store closure.” Source: help.deliverect.com.
Some is not all, and EatEasy is not named among the channels that do. A brand cannot assume its middleware will carry an EatEasy closure into an operations report, and the absence of a log entry cannot be read as the absence of a closure.
That leaves the customer’s view as the only observation point that exists in every case. Put the two facts side by side, what a customer could order at a given minute and what the branch said its hours were, and an interval falls out with a start and an end on it. The interval is the same shape whether the cause was an item toggle, a courier gap, an approval that never came back or a session nobody kept open. Kitchain (kitchain.co) watches EatEasy listings in the United Arab Emirates on exactly that basis, because on this platform there is no second source to check it against.
A closing word on confidence. Almost everything above is either an integrator speaking about its own product or our own reading of a public script, and neither is EatEasy stating a rule. Where a page in this series can quote a platform describing its own behaviour, this one cannot, and that absence is the most reliable finding it contains.