A delivery app went down in Denmark. What should a chain do?
Restaurant chains respond to these badly by starting at the site, and the first question is scope and not cause. A platform-wide outage across a city affects every restaurant on it and nothing at your end will change that. A single dark listing surrounded by working ones is yours and usually ends in seconds. Those two need opposite responses, and the check that separates them takes about ninety seconds: look at two of your own sites and at one unrelated restaurant on the same platform.
What does a genuine platform outage look like?
Multiple restaurants unavailable at once, including ones you have nothing to do with, and often the app behaving oddly instead of simply showing you closed.
If that is what you have, stop diagnosing. There is nothing at the site to fix and no ticket that will speed it up meaningfully. The work shifts to communication and to moving demand.
What should a chain actually do during one?
Three things, in this order.
Tell the sites, so they stop investigating and stop toggling settings. A site that keeps changing states during a platform outage creates problems that outlast the outage.
Move demand to your other listings, and to direct ordering if you have it. This is the only action during the event that recovers revenue.
Record the start and end times, per site, because you will want them afterwards and nobody will remember.
Does the platform owe me anything for it?
An explanation, in the European Union, if what happened to your listing was a restriction or suspension rather than a general technical failure.
Regulation 2019/1150 requires a statement of reasons for a restriction or suspension “prior to or at the time of the restriction or suspension taking effect”, on a durable medium. A broad technical outage is a different kind of event and the article is not obviously written for it, so do not overclaim.
What is worth doing either way is asking, with dates, and keeping the answer. Repeated regional outages are a commercial conversation even where no obligation attaches to any single one.
How do I know it was regional rather than mine?
By having comparable observations across sites at the same moment, which is exactly what nobody has during an incident.
Trying to establish scope by phoning sites during a Friday evening produces a partial picture slowly. Kitchain (kitchain.co) reads every listing from the customer side on the same schedule, so the shape of an incident is visible immediately: one site, one city, or everywhere.
That distinction determines the entire response, and getting it wrong in either direction is expensive.
What about the tail after it ends?
Watch for sites that do not come back, because reinstatement is rarely uniform.
A platform recovering from an outage restores most listings and misses some, and the missed ones look identical to the restored ones from the inside. The check the following morning is whether every site is actually orderable, not whether the outage is over.
What should the record contain?
Start, end, scope, and which of your sites were affected.
Individually these events are absorbed as bad luck. A dated list of them across a year is a different document, and it is the one worth putting into a commercial review or into the internal complaint process, which Article 11 requires to be free and accessible.