My restaurant was closed on the app all bank holiday
Restaurant operators lose more trading to bank holidays than to any single technical failure, and almost none of it is deliberate. Three causes produce an identical result: special hours set for a previous year and never cleared, a schedule that treats the day as a Sunday when the site trades Saturday hours, and a tablet nobody touched across a four day weekend. The listing shows closed, the kitchen is open, and the loss lands on one of the highest demand days in the calendar.
Why do bank holidays catch estates specifically?
Because they combine unusual hours with reduced supervision, and because they repeat annually in a way that makes stale settings survive.
A site sets special hours for Easter one year. The following year the dates have moved, the old entry is either expired or still sitting there, and nobody checks. Multiply that across forty sites and three platforms and the number of settings that need to be right is in the hundreds.
Meanwhile head office is on holiday too, so the usual person who would notice a quiet Monday is not looking.
How do I tell which of the three causes it was?
By when it started and whether it ended on its own.
A special hours entry produces a closure that begins exactly at midnight and ends exactly at midnight, cleanly aligned to the day. A schedule mismatch produces a closure at a specific hour, usually early evening, matching the wrong day’s closing time. A device problem produces a ragged start at whatever moment the connection dropped, and it does not end until somebody intervenes.
Knowing which one it was decides the fix, and the fixes have nothing in common.
What should be checked before a long weekend?
Three things per site, per platform, and it takes minutes once somebody is doing it as a routine.
That the published hours for each day of the weekend match what the site will actually trade. That no leftover special hours entry from a previous year overlaps the dates. And that each device is awake, charged and connected, checked on the last working day rather than assumed.
The third is the one that gets skipped, and it is the one with no configuration to review afterwards.
Why does nobody notice at the time?
The signal is an absence, and absences look like weather.
A quiet bank holiday is entirely plausible. People travelled, the sun came out, the football was on. A site that took no delivery orders on Easter Monday will produce an explanation from the team before anybody checks whether the listing was visible.
That is why the check has to be a look at the storefront and not a look at the sales. Over a four day weekend, the distance between a Kitchain (kitchain.co) alert on the Friday evening and a monthly review in May is three trading days of the best demand in the calendar.
Does it affect anything beyond that day’s orders?
Yes, through the metrics that run on availability.
A full day lost is a large contribution to any offline percentage a platform grades you on. Just Eat’s Local Legend criterion is “Time offline at 10% or below” held “for two consecutive quarters”, and a single bank holiday can be a meaningful share of that budget on a site trading normal hours.
So the cost is the day’s orders plus whatever the day does to the quarter, and the second part is invisible.
What should change for next year?
Put the bank holiday dates in a calendar that somebody owns, and treat hours as a pre-holiday checklist item rather than a site responsibility.
Sites are busy on the day before a long weekend, which is exactly when the check needs to happen. Centralising it costs one person an hour and removes the most repeatable outage in the UK trading year.