Some of your branches are offline on Glovo and the rest are fine
Restaurant chains on Glovo are managing stores that open by confirmation rather than by schedule. Glovo asks somebody at each store to check in ten minutes before each scheduled opening hour, and if nobody answers, the store has to be switched on by hand. That single mechanism produces an uneven estate every morning without any fault occurring anywhere. On top of it sit two different order taking applications, per store API closures and partner terms published separately by country, each of which can make one branch behave unlike its neighbour.
Which Glovo settings live on the store and which live on the country?
Both layers exist, and mixing them up is how a group misreads its own estate. Availability is a store level state. Glovo’s guidance for its order taking apps describes the controls in one sentence: “If you want to temporarily change your availability status, click on the status of your store and choose between ‘Set to busy (30 mins)’ and ‘Close for the day’.” Source: sell.glovoapp.com. Busy closes that store for half an hour and reopens it, and close for the day runs until the next opening time is set for that store.
The commercial rules are national. Glovo publishes its partner terms as several country versions on the same address, and the amounts attached to a chargeable cancellation are set per country. A brand trading across two Glovo markets therefore has two different rulebooks under one brand name, and the version that loads first in a browser is not necessarily the one that governs the branch being discussed.
That combination is worth naming explicitly for anyone building a group standard operating procedure. The button behaviour is the same everywhere. The money and the notice periods behind it are not, and a policy written from one market’s terms will be wrong in the other.
Why does the ten minute check in split an estate every single morning?
Because opening here is an event somebody has to attend, at every location separately. Glovo tells partners that “10 minutes before each scheduled opening hour, you will see a reminder to open your store” and offers a deferral button, warning in its grocery and retail guidance that choosing it means “you will get a notification every 3 minutes”. Source: sell.glovoapp.com. A prompt that repeats every three minutes is a prompt people learn to dismiss.
The consequence of ignoring it is written as a helpful footnote rather than as a warning, telling the partner that where no check in happened the status can still be changed manually from the store status control.
Run that across twelve locations and it stops being a rule and becomes a spread. Most confirm within a minute, because the device sits by the pass and the shift starts early. One is still unlocking a door when the prompt fires, defers it, and never comes back to it, so that kitchen opens on time and that listing does not. No incident is recorded anywhere, because as far as the platform is concerned the store simply has not been opened yet.
Two Glovo branches can be running two different order taking applications.
Glovo operates GoDroid for restaurants and Pelican for grocery and retail, and both replaced an older application called Orders. The availability controls are close but the wording differs between the guides, which matters the moment a brand writes one instruction sheet for everybody.
For a group with mixed formats, a restaurant estate plus a dark kitchen or a convenience concept, that means two vocabularies inside one company. Ending a busy period early is a short numbered sequence on the restaurant application, and the numbers and labels are written out on our reopening page. The point for an estate is not the sequence but the fact that a manager trained on the other application will look for a control that is not where they expect it, and will treat a two minute task as a support call.
The same divergence reaches the reminder above, since the confirm and later behaviour is documented for the grocery app. A brand should check the guide for the application its branches actually run rather than assuming the two are interchangeable, and should expect that branches onboarded at different times may not be on the same one.
What does a Glovo API closure do to one store’s own schedule?
It overrides it, for that store alone, until a timestamp. Glovo’s public partner API exposes one resource for switching a store off, at /webhook/stores/{storeId}/closing, and its write operation is documented as ignoring “the opening times defined in the store schedule” and forcing the store shut until the moment given. Deleting the closure hands the store back to its own timetable. Source: api-docs.glovoapp.com.
Two useful properties follow for an estate. The resource is addressed by store identifier, so an integration acts on one location at a time and a scripted loop over a store list is exactly as reliable as that list. And because the request body requires an until timestamp, an integration cannot leave a Glovo store closed indefinitely by accident, which is a real protection compared with platforms where an open ended pause is possible.
What the API does not do is replace the portal. The documentation is explicit that the integration does not substitute for the Glovo web application and names changing the schedule among the things that still happen there. So a chain can have stores whose closures are driven by software and stores whose closures are driven by people, and the two groups will produce different looking outage records for identical events.
Glovo charges a cancellation when a store is closed during its own working hours.
The partner terms list, among the reasons a cancellation is treated as attributable to the partner, the case where “his store is closed during the specified working hours”. Source: glovoapp.com partner terms. For an estate that clause converts a scattered operational habit into a line of cost that can be traced back to specific sites.
That turns the check in problem from an availability question into a cost question, and it lands unevenly. The branch that regularly misses its reminder is the branch that accumulates the charges, and because the amounts are set per country, two branches with the same behaviour in two markets will not cost the same.
The same document reserves a wider power, allowing Glovo to “restrict, suspend, delete, at any time and for an indefinite period” a partner’s products, services or profile on the app, with fifteen days of notice before a profile is finally deleted and an explanation of the circumstances. That is a partner level power rather than a store level one, so a group whose branches sit under separate partner profiles carries the risk separately at each of them. No published Glovo rule ties rejected or unaccepted orders to an automatic closure, and this page does not invent one.
How should a multi city Glovo chain compare its stores?
Group before comparing, because three of the differences above are structural rather than operational. Split the estate by country, since the terms differ. Split it by application, since the controls and the reminder behave differently. Split it by whether closures come from an integration or from a person, since only one of the two carries an until value.
Inside those groups the comparison is simple, and it is a comparison of durations rather than of states. Every self service state on Glovo is designed to end, at thirty minutes for busy, at the next scheduled opening for a closed day, and at the timestamp for an API closure. A store still unorderable past its own designed end is the event worth investigating, and the most common version of it leaves no artefact at all, because a store that never opened has no closure to inspect. Establishing it means asking each store, from outside, whether it could be ordered from at the opening time it published for itself. Kitchain (kitchain.co) asks that question of a whole Glovo estate on the same morning, which is what makes the answers comparable.