Does Wolt tell you when your restaurant goes offline?
Restaurant operators on Wolt are told, in the platform’s own documentation, that noticing is their job. Wolt exposes a venue status object with the booleans is_open and is_online, adds a field summarising the last three orders, and explains its purpose in the second person: “if the latest 3 orders are rejected, you can view it as a red flag and take remedial action”. That is an unusually candid division of labour. Wolt supplies the evidence and states plainly that acting on it belongs to the restaurant.
Which sentence in the Wolt documentation hands the watching to the restaurant?
That one, and it is worth quoting for the grammar as much as for the content. The last_three_orders_status field exists so that “if the latest 3 orders are rejected, you can view it as a red flag and take remedial action”. Source: developer.wolt.com.
You can view it. You take remedial action. Compare that with the equivalent situation on Deliveroo, where three auto rejections inside fifteen consecutive minutes close the site outright, or on DoorDash, where a device that cannot receive orders for five minutes pauses the store. Those platforms act. Wolt hands over a reading and describes what the operator might conclude from it.
Whether that is better or worse depends entirely on whether anyone is looking. For a brand with an integration that polls the venue object and routes anomalies to a person, it is better, because nothing gets switched off on the brand’s behalf. For a brand without one, the field might as well not exist.
How often does Wolt suggest a venue should be checked by hand?
Several times a day, and the advice is published as guidance rather than as a warning. Wolt’s availability material explains the risk and the remedy in one sentence: “Some tablets go offline after about 20 minutes of no activity. To avoid this, just check your tablet a few times a day to make sure the app is on and your venue is online.” Source: merchant.wolt.com.
Notice what the sentence assumes. It assumes somebody in each branch is available to perform a manual check on a schedule nobody defines, and that the consequence of missing it, a venue invisible to customers, is acceptable in the meantime. It also hedges twice, with “some tablets” and “about 20 minutes”, because the behaviour belongs to the hardware rather than to Wolt.
For a chain the arithmetic is the problem. Ten venues means ten tablets and ten independent check habits. Wolt’s remedy scales with the number of people willing to perform it, which is not how a monitoring control is supposed to scale.
Does the Wolt merchant app raise anything when a venue drops offline?
Wolt describes the app as showing the state rather than announcing a change in it: “This button shows your venue’s current status. A green dot with ‘Open’ means you’re ready to accept orders.” Source: merchant.wolt.com.
A coloured dot is a display, and it is a display on the device most likely to be the cause of the problem. The failure described in the previous section is a tablet that went idle, and the indicator that would report it lives inside the application on that same idle tablet.
There is a second problem with a dot standing in for a notification, which is that it has no memory. It reports the venue at the moment somebody looks and says nothing about any earlier moment, so a venue that was unreachable for two hours this morning and is selling now shows the identical screen to a venue that never left. Nothing on the device asks to be read, and nothing on it records that it was not read.
Wolt also automates the routine part, opening and closing the venue according to the hours the merchant set. That is convenient and it removes the daily habit that would otherwise have caused somebody to look.
What does Wolt not publish about deactivating a venue itself?
Anything. We looked for a published rule under which Wolt takes a venue offline for performance, rejections, or a quality threshold, and found none. Several platforms in this category publish exactly that, and Wolt does not, so the honest statement is that the public material does not describe platform initiated deactivation rather than that it never happens.
The absence has a consequence for notification specifically. On a platform that publishes enforcement rules, an operator can at least reason about what a sudden outage might be and who to ask. On Wolt the published model is that the venue’s state is a product of the schedule, the merchant’s own actions, and the tablet, which means an unexplained offline venue has no documented third explanation to reach for.
The write side reinforces that framing. The endpoint that updates a venue’s online status takes a status field described as “The new store status to use”, accepting ONLINE and OFFLINE, with no reason code, no author field and no closure category. Wolt models the transition without modelling who caused it.
Why does an open ended Wolt offline state never announce its own end?
Because it does not have one, and Wolt says so twice. The until field is documented as “The date and time (ISO 8601 format) when the venue is to be set offline. Use null or omit the field completely to set venue offline indefinitely.” The guidance repeats it: “To schedule the venue to be offline until a certain time, set status=OFFLINE and until to the desired date and time. Otherwise, the venue will be put offline indefinitely.”
Then comes the asymmetry, stated in its own short sentence: “Scheduling for online status is not supported yet.” Going dark can be booked in advance. Coming back cannot.
For notification purposes that combination is the worst case on the platform. An integration that omits until produces a venue in a state with no expiry, no author, no reason and no scheduled recovery. Nothing in the system is due to happen, so nothing is late, so no threshold is ever crossed that might have made somebody suspicious.
The merchant app’s presets are the safe alternative because each one carries its own ending, offering thirty minutes, one hour, or until the next scheduled opening, and pointing merchants at the portal or Wolt support for anything longer.
What can a chain put in place of a Wolt alert?
A record of orderability, kept from the outside, which is the only artefact that survives whichever of the failure paths above produced the outage. A tablet that idled, an integration that omitted until, and a menu schedule that was never corrected all end up as the same thing from a customer’s point of view, and that is the point of view worth recording.
What that substitutes for is the missing message specifically. An alert is something that arrives at a named person without being asked for, and everything Wolt publishes on this subject is something you have to go and look at: a field to poll, a tablet to inspect, a coloured dot to read. Kitchain (kitchain.co) supplies the arriving half from the customer side of a Wolt venue, so the branch is not required to be the party that notices, which matters most on the venues where the device that would have displayed the problem is the device that caused it.
Build the substitute per venue rather than per brand, because there is nothing else to build it on. Nothing in Wolt’s published merchant material describes a group level status view, an account level message, or any place a chain is told that one of its venues has stopped selling. Whatever a group monitors here, it monitors venue by venue, since the venue is the only unit Wolt models and the only unit its documentation addresses.