Does Bolt Food tell you when your restaurant goes offline?
Restaurant operators on Bolt Food are told exactly once, in one place, by a colour. The platform’s own training material describes what happens when a restaurant stops taking orders: “At the top of your screen, a red bar will appear saying, “You’re offline”.” That bar lives on the device in the branch. The merchant portal holds a schedule and a set of performance reports, and Bolt publishes no store status API, so a red bar seen by whoever is standing next to the tablet is the entire notification layer.
Which surface does Bolt Food use to say a restaurant is offline?
The tablet, and the instruction sequence makes the scope clear. Under a section headed “Pausing new orders”, Bolt tells staff to open the main menu and “Click the ‘Go offline’ button”, then describes the result: “At the top of your screen, a red bar will appear saying, “You’re offline”. Clients can’t order from your restaurant until you resume accepting orders. To do so, click the ‘Go online’ button.” Source: Bolt restaurant app training guideline.
Every element of that description is local. Your screen, the button, the bar. There is no recipient outside the room.
For a single site that is proportionate, because the person who pressed the button is the person who can unpress it. For a brand with branches in several cities it means the state of each listing is expressed as a visual on a device that head office has never seen, and the more branches there are the more red bars exist that nobody is looking at.
How long after the fact does the Bolt Food merchant portal report availability?
After the period, which is a different job from telling you now. Bolt’s merchant portal guide describes a reporting layer covering operational metrics, online availability among them, alongside unfulfilled orders, order delay rate and complaints, and a home view that flags irregularities including cancelled or unaccepted orders. Source: Bolt Food Merchant Portal and Menu Editor Guide.
Reporting availability as a metric is genuinely useful for a monthly review and useless during a Friday service. It answers the question of how much trading time was lost across a period. It does not answer the question of whether a branch is dark right now.
It also has a second effect that operators tend to discover late. Online availability being a scored metric means an offline branch costs the brand twice, once in the orders it did not take and once in a number it is judged on afterwards. A brand that only reads the portal is learning about both costs at the same time, well after either could have been avoided.
The portal is where the schedule lives too, described as informing customers about when they can place an order and instructed to reflect the kitchen schedule, with a separate control to add holiday hours for closures. So the surface that defines when a branch should be available is the surface that reports on availability last.
Does Bolt Food publish a status endpoint an integration could subscribe to?
We found none. Bolt Food publishes no public partner API for store status, no webhook catalogue and no developer documentation of the kind Keeta, Wolt, Glovo and Uber Eats maintain. That is a factual absence rather than a criticism, and it closes off the route most multi site brands use to automate this.
The consequence is worth stating plainly. On platforms with a status endpoint, a chain that wants to know can build the knowing. On Bolt Food there is no endpoint to build against, which means every path to knowing runs through either a person in the branch or the storefront a customer sees.
It also means no third party integration can fill the gap on the brand’s behalf. Where a middleware layer can mirror a channel’s closure into an operations report, it can only do so if the channel tells it, and Bolt does not publish a mechanism by which it would.
What happens on Bolt Food when busy mode ends by itself?
The restaurant comes back and nobody is informed, which is the correct behaviour and still worth understanding. Bolt publishes a short list of busy lengths and undertakes to end the state itself when the chosen one runs out, and that undertaking is quoted on how to get a Bolt Food restaurant back online. The return happens without a message because no message is needed for a state that was always going to end.
Busy mode is also the one state where Bolt does send a message, and the recipient is not the restaurant. The guide explains that cooking time “will be automatically changed to the selected amount of time” and that Bolt will “notify customers about longer expectation of their orders”. So the platform has a working notification channel, it uses it, and it points at the guest.
The important asymmetry is between the two states. Busy mode ends on a timer with a documented rule. Going offline has no timer, no expiry and no scheduled return anywhere in Bolt’s published material, so the two behave in opposite ways while sitting one tap apart in the same menu. A manager who has learned that Bolt brings you back will be right about one of them and wrong about the one that matters.
Which Bolt Food change is made by a rejection reason rather than by a decision?
Menu availability, and it happens during the busiest minute of the shift. Bolt describes the flow: rejecting an order prompts for a reason, and “If you mark the reason as Out of stock items, you will be prompted to select the item in question, which will automatically mark it out of stock.”
That is a menu edit performed as a side effect of a rejection. Nobody set out to change the catalogue, no approval was involved, and no message goes anywhere. From that point the item follows its own published timings, which differ depending on which sold out state was chosen and are set out with Bolt’s wording here.
The notification consequence is the part worth holding on to. A dish can leave the menu, sit out of stock across several services and be hidden entirely, and the only trace of the decision is a reason code typed during a rejection. Nothing about that sequence produces a message to anybody who was not in the room, and the catalogue a customer sees drifts away from the catalogue head office believes it is selling.
What has to be handed over at the end of a Bolt Food shift?
The online state, in the same way a float or a key is handed over, because nothing in the platform will do it. An offline restaurant at closing time is an offline restaurant the following morning, and the red bar that would have said so is on a tablet that was locked in an office overnight.
That makes the useful control a handover check rather than an alert. Two questions at the end of every shift, whether the restaurant is online and whether anything is still marked sold out indefinitely, catch both of the states Bolt does not end by itself.
The independent check is the storefront. Asking a branch, from outside, whether it will take an order, and holding that answer against the hours the branch published, gives a start time and an end time for every dark period. It does not matter which tablet the red bar appeared on, and it works for the branches nobody visited that week. Kitchain (kitchain.co) collects that reading on Bolt Food listings from outside the merchant account, which on a platform that publishes no status endpoint is the only mechanised view a brand can have of its own availability.