My Dutch listing shows closed and I never closed it
Restaurant operators in the Netherlands run into this most often on an evening when nobody has time to investigate, so the triage has to be short. Four causes cover almost all of it. A device that lost connection or fell asleep. A schedule entry that does not match today. A state somebody at the site set and did not clear. Or a closure the platform applied, which is the only one you cannot end yourself and the only one that carries a right to an explanation.
Which of the four is it likely to be at this hour?
That depends entirely on the hour, and the answer at nine in the evening is not the answer at nine in the morning.
A closure that appears at opening is almost always a schedule: an entry from a previous period, or a public holiday that moved. A closure that appears mid service is almost always a device or a state somebody set under pressure. A closure that was there overnight and is still there is the one to treat as the platform’s until shown otherwise.
Reading the clock first narrows the investigation before you have made a single call.
What if the overnight one turns out to be the platform’s?
Then you are owed an explanation, and owed it already.
Regulation 2019/1150 requires a platform restricting or suspending service to give a statement of reasons “prior to or at the time of the restriction or suspension taking effect”, on a durable medium. Article 4(3) adds the right to clarify the facts within the internal complaint process, and Article 11 requires that process to be free and accessible.
Ask in those terms. It is a shorter exchange than asking why the store is closed, and it produces something you can keep.
Why do these happen in the evening?
Because that is when the conditions align, and it is the single most useful pattern to know.
Devices lose connection when premises networks restart. Automatic closures trigger after a run of rejected orders, which happens during a rush. Pauses are set when the kitchen is under pressure. All three peak in the evening, and the evening is when the fewest people are watching.
On a platform where a closure does not lift itself, an incident starting at ten at night runs until somebody looks in the morning. That is not a slow response, it is the absence of any response.
How would I know at ten at night?
Only if something is watching the storefront rather than the kitchen.
Nobody inside the building can see this. The site is staffed, the tablet appears normal, and the absence of orders looks like a quiet Tuesday. Kitchain (kitchain.co) reads the listing as a customer sees it and messages when it stops being orderable, which converts a lost night into a ten minute interruption.
What should I record afterwards?
The hour it began, because that is the field the others hang off.
Cause and duration matter, and neither of them tells you where to intervene. A site whose incidents cluster at seven in the evening has a service problem. A site whose incidents cluster at opening has a scheduling problem. A site whose incidents cluster overnight has neither and is being closed by somebody else.
Three sites, three different fixes, and the start time is what separates them.