How do I know when a Portuguese branch goes offline?
Restaurant chains in Portugal ask this after discovering an outage late, and the answer is uncomfortable because it rules out the two sources everybody reaches for first. A partner portal answers what is true now, which is useful when opening the shop and useless the following week. Sales data cannot distinguish an invisible storefront from a quiet evening, because both produce no orders. Knowing requires reading the listing from the customer side, on a schedule short enough that an evening outage cannot hide between checks.
Why is the portal not enough?
Because it is a control panel and not a log.
It shows the present state and lets somebody change it. It does not keep an auditable history of when the listing was orderable, and it does not compare one site against another. So a manager looking at a portal at nine in the morning learns nothing about what happened at nine the previous evening.
That is not a defect in the product. It is what portals are for.
Why can I not work it out from orders?
Because absence is ambiguous, and it is the single most common analytical error in this subject.
Zero orders between eight and ten is consistent with an outage and equally consistent with a slow Tuesday. Working backwards from revenue produces a list of suspicious hours, not a list of incidents, and suspicion does not survive a conversation with a site or a platform.
In a market with pronounced seasonality, which describes much of Portugal, the ambiguity is worse. A quiet week in a coastal town in November is expected, so nothing prompts investigation.
What does the outside check actually involve?
Opening the listing as a customer would, from an address in the catchment, and recording whether it was orderable.
Done once, that is a spot check and it finds only persistent problems. Done repeatedly on a schedule, it produces a series, and the series is what answers the question you are asking. Kitchain (kitchain.co) reads each listing that way, per site and per platform, and messages when one stops being orderable.
The interval matters more than anything else about the method. It sets the smallest incident you are capable of seeing.
What do I do with the alert when it arrives?
Triage in the same order everywhere: device, schedule, a state somebody set, then platform.
The first three are yours and end in seconds once identified. The fourth is not, and there the European rules give you something specific to ask for. Regulation 2019/1150 requires a statement of reasons for a restriction or suspension “prior to or at the time” it takes effect, and Article 11 requires a free internal complaint route behind it.
Does this change how head office runs?
It should reduce the reporting, not add to it.
The output that works is a short exception list read before service by one named person with authority to call a site. Not a dashboard. Sites that were fine do not need to appear at all.
Anything longer gets skimmed within a month, and the value of the whole exercise is in three lines and three phone calls.
What interval is short enough?
Short enough that the smallest incident you care about cannot fall between two observations.
That is the whole specification, and it is worth stating as a decision rather than inheriting it. A group checking once a day can only ever discover that a site had a bad day. A group checking every few minutes can discover that a site was closed between eight and ten on a Friday, which is a different sentence and produces a different phone call.
Pick the interval by naming the shortest outage you are willing to pay for, then check faster than that.