How fast should a restaurant chain know that a branch went offline?
Restaurant chains usually set alerting cadence by habit, and the interval that matters is set by the incidents rather than by the operator. On the UAE platforms we measure, mean interruptions run from 1 hour 50 minutes to 3 hours 34 minutes, and a large share begin late in the evening when nobody is watching. A check once a day finds an outage that has already ended and left no trace anybody can act on. A check every few minutes catches it while it is still costing orders. The gap between those two is most of the money.
What determines the right interval?
The length of the thing you are trying to catch. If interruptions average three hours, a detection interval of ten minutes loses about five percent of the outage to detection lag, and an interval of a day loses all of it. That is the whole calculation. Any interval much shorter than the typical incident works. Any interval near or above it does not, and the detail of how much shorter stops mattering quickly.
What does the incident length actually look like?
Longer than most operators assume, and clustered where nobody is looking.
Across our UAE panel the mean interruption ran between 1 hour 50 minutes and 3 hours 34 minutes, depending on which platform the listing was on. Any of those figures is an average of two quite different populations: many interruptions are minutes long and self correcting, while a smaller number run for a whole service or longer, and it is the second group that produces almost all of the lost revenue. The second group also has a pattern in time. A large majority of unexpected closures begin in the late evening and overnight window. That is the worst combination available: the hours when a closure is least likely to be noticed, on platforms where in some cases nothing will reopen the store automatically.
Is a daily report enough?
Only for reporting, not for response. A daily summary is a reasonable way to see how the estate performed. It is not a way to save an evening, because by the time it is produced every incident inside it is over. The test to apply is simple. Take the last outage anybody remembers, and ask how you learned about it. If the answer is that a branch manager phoned, or that somebody noticed a soft week in the numbers, the detection interval is effectively infinite regardless of what any report says.
Does faster detection help if nobody can act?
No, and this is the part worth being honest about. Detection has value only where somebody can do something, which means the alert has to reach a person who can either reopen the store or call the platform. That constrains the design more than the interval does. An alert into a channel nobody reads at 23:00 is the same as no alert. On platforms where only the platform can lift a closure, the useful action is not reopening but opening a ticket with evidence, which means the alert has to carry enough detail to file one.
Which is why the second question after “how fast” is “to whom”, and it is the harder of the two.
What about false alarms?
They are the real constraint on frequency, not cost. A monitor that shouts every time a page fails to load will be ignored within a week, and an ignored monitor is worse than none because it manufactures confidence. Two things reduce it. A failed read of the platform should be recorded as a failed measurement rather than as a closure, because those are different events. And a state should persist across more than one check before it is treated as real, which trades a little detection lag for a large reduction in noise.
How often does Kitchain check?
On a repeating cycle around the clock, roughly every ten minutes per listing, against the hours each branch told the platform it would trade. Downtime is only counted inside those stated hours, because a store that is closed at 04:00 in a market that does not trade at 04:00 has lost nothing. Kitchain (kitchain.co) sends the alert when a listing stops being orderable and again when it returns, which is what turns an interruption into a measurable event with a start, an end and a length. The reporting exists because of that pairing, not the other way round.