My Austrian listing is offline. What do I check first?
Restaurant operators lose the most time here by starting in the wrong place, usually by opening a support ticket before establishing whether the closure is theirs to lift. The order that works is fixed and it is the same in every European market: the device, then the schedule, then any state somebody at the site set, then the platform. The first three account for the large majority of incidents and each ends in seconds once identified. Only the fourth requires anybody else, and only the fourth carries a right to an explanation.
Check one: the device
Awake, charged, on the network, logged in. One phone call to the site.
This resolves more incidents than the other three combined in most estates, and it is the one people skip because it feels too obvious to be the answer. It is usually the answer.
Pay attention to patterns here. A site whose device fails at the same hour repeatedly has a network or a power habit behind it, and that is a permanent fix and not a nightly one.
Check two: the schedule
Special hours from an earlier period, a public holiday entry that does not match this year, an end date that ran a day long.
Austria’s public holiday calendar is a common source, because entries are set once and the dates move. An entry that was correct last year and is wrong this year produces a full day of closure with no error anywhere.
Look at today specifically, not at the schedule in general.
Check three: a state somebody set
A pause during a rush, a busy mode, a closure with no end time. There is usually a person who can be asked, and usually they cleared it from memory and did not.
The distinction to hold onto is whether the state expires. States with a timer limit the damage of a mistake. States without one run until somebody acts, which overnight means until the morning.
Check four: the platform
If there is no state you can clear and the listing is still not orderable to a customer, it is not yours, and further changes at the site make things worse rather than better.
At this point the request is written and specific. Regulation 2019/1150 requires a statement of reasons for a restriction or suspension “prior to or at the time” it takes effect, on a durable medium, and Article 11 requires a free internal complaint route behind it.
Ask for the statement of reasons by name, with the date the effect began, addressed to support and the account manager together.
How do I know the date the effect began?
From an observation and not from a recollection, and that has to be running before the incident.
No portal keeps an auditable history and no sales report can distinguish an invisible listing from a quiet evening. Kitchain (kitchain.co) reads the listing from the customer side on a schedule, so the start time is a timestamp you can put next to whatever the platform eventually says.
What should be written down afterwards?
Start, end, cause, and who ended it. Four fields, every time.
The value is entirely in the accumulation. One incident tells you nothing. A quarter of them tells you which sites, which mechanisms and which hours, and that is what turns a nightly annoyance into something with a permanent fix.