Does Ninja tell you when your restaurant goes offline?
Restaurant chains on Ninja are working with a portal that has a real notification layer and points it somewhere else. The Ninja partner portal’s own interface strings carry browser notification code, a live socket connection, and a payload built around the rider, with a pickup estimate and a nearby flag. Branch status changes are handled differently. Those produce a confirmation inside the session that made them, such as “This branch is now open”, and nothing that travels beyond it.
Does the Ninja partner portal raise browser notifications at all?
Yes, and that makes Ninja unusual in this category. Most partner portals in this set are pages you visit. The Ninja portal at restaurant-portal.ananinja.com is built to ask a browser for notification permission and to raise a system notification with a title, a body and an icon, keyed by a notification identifier so the same one is not shown twice.
That matters because it removes the usual excuse. A platform without any push mechanism cannot alert anybody by definition. Ninja has the mechanism, has wired it into the merchant surface, and has chosen what to send through it.
It also means the honest answer to this page’s title is conditional rather than flat. Whether a Ninja operator is notified depends on what the portal has been built to push, and on whether the browser holding the portal granted permission in the first place.
What is inside a Ninja push notification, and is the branch mentioned?
The rider, in the fields our reading can see. The notification handler in the portal’s interface strings carries a pickup estimate for the rider and a derived flag for the rider being nearby, timestamped and cached. That is a courier logistics message aimed at the person assembling the order.
Nothing in the same handler describes a branch level availability change. The status controls have their own vocabulary elsewhere in the portal, with the banners “Your restaurant is currently busy!” and “Your restaurant is currently closed!”, the actions “Mark Available”, “Mark Busy”, “Close for Maintenance” and “Open Restaurant”, and a success confirmation reading “This branch is now open” with the explanation “The branch is now open and ready to receive orders.”
Those are page states and toasts. A toast is rendered to the session that triggered the action, which means the confirmation of a branch being closed for maintenance is seen by the person who closed it and by nobody else.
The gap this leaves is specific to Ninja’s own design. The platform tells a branch that a rider is approaching, an event lasting minutes and already visible to anyone in the kitchen, and does not push the event that can cost a whole evening.
What happens when the Ninja portal loses its live connection?
It tries again, quietly. The portal’s own interface strings carry a socket client with reconnection handling and messages including “Socket Reconnecting…”, “Socket Reconnection Failed” and “Not connected or connecting”, alongside a forced close path.
Those strings are diagnostic rather than operational. A portal that has failed to reconnect is a portal that has stopped receiving live order traffic, which produces exactly the symptom an operator would describe as the branch having gone quiet, and it produces it without the branch status having changed at all.
For a chain that is the harder failure to reason about, because the branch is genuinely open on the platform and genuinely not being worked in the building. Whatever the portal shows about status is correct and irrelevant. Ninja publishes no developer documentation and no status API, so there is no second opinion available from outside the portal.
Which Ninja change is queued for review rather than announced?
Menu content, and the portal says so at the moment of submission: “Change requested! and it will reviewed by admin shortly.” The wording is the platform’s, typo included.
An item change therefore has three states rather than two. Requested, reviewed, live. The portal tells the merchant that the first has happened and does not describe a message for the second or third, so an operator who submits a change and assumes it took effect is assuming something the interface did not say.
This is worth holding next to availability because the two failures look identical to a customer. A dish that never came back from review and a branch that never came back from maintenance both present as something a guest cannot order. Ninja distinguishes them carefully inside the portal and announces neither of them outside it.
Where does Ninja point a restaurant that needs an answer?
At support, consistently and by name. The portal carries a “Contact Support” action, a dedicated “Eid Working Hours – Support Request” flow, an access message reading “Access Denied: Contact support to get the required permissions.”, and a family of generic errors that all end the same way, including “An unexpected error occurred. Contact support.”, “Record not found. Contact support.”, “Server issue. Contact support.” and “System issue. Contact support.” A third party support widget is embedded in the same application.
Four different error conditions resolving to the same instruction is a clear statement about the intended direction of traffic. The restaurant contacts Ninja.
The permission message is the one with operational teeth. If the person on shift cannot change a status, the length of any closure is set by how long it takes to reach somebody who can, and on Ninja that is compounded by the one closure type that will not clear itself: “To receive orders again, you have to open the restaurant manually by pressing ‘Open Restaurant’ action!”
What does a Ninja chain have no way of being told?
That a branch stayed shut. Ninja is careful about durations, writing the return into the option, with “Change to busy 30 mins” described as “Will receive orders after 30 minutes” and the overnight option described as the restaurant opening at the usual time in the morning. Those promises make the exceptions legible, and the exception is a maintenance closure that requires a person.
Nothing in the portal watches for a state that outlived its own description. A branch closed for maintenance on a Sunday afternoon by a manager who then goes home is a branch that will still be closed on Monday, and every screen involved will be reporting that situation accurately.
Since there is no API, the only external check is the storefront itself. Whether each branch can be ordered from right now, compared against the hours that branch published for today, catches the maintenance closure nobody reopened, the socket that never reconnected and the branch sitting outside hours somebody entered incorrectly, all as one timestamped interval. That is what Kitchain (kitchain.co) records on Ninja listings across the four markets its portal serves, which are Saudi Arabia, Bahrain, Kuwait and Qatar.
One note on how to read this page. Everything above about notifications and sockets is our own dated reading of the portal’s public interface strings rather than a statement Ninja has published, and front ends change. The interface strings are quoted as they appear, and the conclusion that the push payload concerns the rider is ours.