Some of your branches are offline on Ninja and the rest are fine
Restaurant chains on Ninja are looking at one branch at a time whether they want to or not. The Ninja partner portal moves between locations through a picker, described in its own interface text with the tip “you can change your branches from this dropdown menu”, and it holds a separate set of states for each. Some of those states end on a timer and one of them does not. Add a review queue on changes and a permission gate on the status control, and an estate ends up in several conditions at once without anybody choosing that.
Why does the Ninja portal show you one branch at a time?
Because the branch is the unit of the interface. The portal’s own dictionary, which ships in plain text in the interface dictionary at restaurant-portal.ananinja.com, carries the guided tip “you can change your branches from this dropdown menu” alongside a second one for switching restaurants. Its banners are written in the singular too, reading “Your restaurant is currently busy!” and “Your restaurant is currently closed!”, and its confirmations name a single location, with “This branch is now open” and “The branch is now open and ready to receive orders.”
Nothing in that vocabulary describes a group action. The controls are named “Mark Available”, “Mark Busy”, “Close for Maintenance” and “Open Restaurant”, and every one of them is exercised inside the branch that is currently selected.
For a brand with a dozen locations that has a specific and unglamorous consequence. Checking the estate is twelve clicks through a picker, so nobody does it daily, and a branch that went into an off state on Tuesday is discovered whenever somebody happens to select it. The portal is not hiding anything, it simply has no screen that answers the question a head office actually asks.
What does a mixed set of Ninja closure states do to an estate?
It produces branches that recover at completely different speeds from decisions that felt identical when they were taken. Ninja writes the outcome into each option, which is unusually considerate. “Change to busy 30 mins” is described as “Will receive orders after 30 minutes.” “Change to busy Until Tomorrow” is described as “The restaurant will open at the usual time in the morning to begin accepting orders.” The general rule for timed states reads “Restaurant will receive orders after selection time ends.”, with an early exit noted as “Or you can open it now by pressing ‘Open Restaurant’ action!”
One option breaks the pattern. A maintenance closure carries the instruction “To receive orders again, you have to open the restaurant manually by pressing ‘Open Restaurant’ action!”, and the exclamation mark is the platform’s own.
Across an estate that single exception is where the divergence lives. Three branches that took a thirty minute pause are all back. The branch that was closed for equipment work on Sunday afternoon, by a manager who then went home, is still closed on Monday morning no matter what its schedule says. Mixed rules are harder to remember than uniform ones, which is why this is the state staff get wrong most often.
Every off state also demands a reason, since the portal has separate prompts named “Select Busy Reason”, “Select Closing Reason” and “Select Maintenance End Time”. Those reasons are the raw material for comparing branches later, and they exist only if somebody collects them.
Why can a Ninja branch refuse to open because its shift is too short?
Because the portal enforces a minimum on the working period itself and blocks the action rather than warning about it. Its dictionary carries the message “You cannot open this shift because the number of hours is low. Increase the number of hours.”, alongside a control labelled “Unlock Shift Hours” and a switch reading “Open 24 Hours”.
This is a configuration refusal wearing the costume of an outage. The kitchen is staffed, the manager presses the control, and the platform declines because the hours entered for that branch on that day fall under the threshold. A neighbouring branch with a longer configured shift accepts the same action without comment.
It also explains a class of complaint that sounds impossible when it is reported upward. Somebody says the branch cannot be opened, which is literally true, and the fix is in the working hours rather than in the status. A brand that has standardised its trading hours everywhere except at its newest or smallest locations should expect this to be exactly where it bites.
Ramadan hours apply themselves on Ninja and Eid hours do not.
The portal treats the two seasons differently and says so. For Ramadan it carries the instructions “Click on the “Save” button.”, “The added hours will automatically be applied on the first day of Ramadan.” and “You can always come back and adjust the Ramadan working hours if needed.” For Eid it carries an action labelled “Add Eid Working Hours” alongside “Contact Support” and a request type named “Eid Working Hours – Support Request”.
That asymmetry is a seasonal fault line straight through an estate. Ramadan hours entered branch by branch fire on their own for every branch where somebody entered them, and do nothing at all for the branch that was missed. Eid hours depend on a request being raised and handled per branch, so the branches whose managers raised it early trade on the holiday and the ones who did not are dark on the busiest days of the year.
Neither failure appears as an incident anywhere. Both look like a branch that is simply outside its own opening hours, which is precisely what it is.
Why does a change at one Ninja branch wait for an admin review?
Because the portal routes edits through moderation and tells the user so, with the confirmation “Change requested! and it will reviewed by admin shortly.” The change types named in the same dictionary include “Changed the Time Slots”, “Changed the Location”, “Changed the menu”, “Changed the images” and several others, so scheduling and location edits are in scope rather than only content.
We are not going to state a review time, because Ninja publishes none. What matters for an estate is that submission is not application. A brand pushing the same hours change to eight branches on the same afternoon has made eight requests, and they do not necessarily land together.
The other gate is access. The portal carries the message “Access Denied: Contact support to get the required permissions.”, and sign in uses account details issued by Ninja rather than credentials a brand creates for itself. So the practical recovery time for a stuck branch is the availability of a person who holds the permission for that branch, and across an estate that number is rarely uniform.
How should a Gulf chain compare Ninja branches without an API?
From outside, because the portal only answers about one branch at a time and there is no second route. Ninja publishes no developer documentation we could find, so nothing about an estate can be assembled programmatically from the platform’s own side. What that costs a group is not the effort of clicking through branches, it is the comparison itself: nobody ever sees the estate laid out together, so no branch is ever the obvious outlier.
Group the estate by country first, since the portal’s own list contains Saudi Arabia, Bahrain, Kuwait and Qatar, and Ramadan hours, shift lengths and admin review all behave as local settings inside one shared interface. Then rank the branches by how much of their own published week they were actually sellable in, not by how many closures each one had, because a branch with one forgotten maintenance closure will beat a branch with twelve tidy busy periods on the second measure and lose badly on the first.
That ranking is the artefact a Ninja group does not currently have and cannot produce from the portal, and it is what Kitchain (kitchain.co) assembles across a Ninja estate so that the outlier branch identifies itself rather than waiting to be found.