Breaking a buy button on purpose, and timing the alarm
A working buy button on this site was changed to go nowhere, deployed, and left broken until Frontend Sentinel noticed by itself. Then the fix was deployed, and Sentinel closed the incident only after it had seen the repaired page working.
Nothing loads until you press play.
A page on this site exists only to be broken. It sells nothing, nothing links to it, and search engines are told to ignore it. On 5 October its buy button was changed to lead nowhere and deployed. The page still looked perfect and still loaded quickly, so an uptime monitor would have stayed green. It is the kind of fault found by hand on these sites in September: buy buttons linked to nothing, and buttons opening the wrong product's checkout.
Sentinel opened a critical incident 1.92 minutes after the broken page went live. Before alerting anyone it reproduced the fault twice in a fresh browser, compared the page with an approved reference rather than yesterday's version, and reported desktop and mobile as one incident rather than two alarms. It named the deploy the failure began after, and said how sure it was: the attribution reads timing only, because no changed file in that deploy could be matched to the button.
The original page was then deployed again. Nobody closed the incident. Sentinel checked again, waited for two healthy runs on each viewport, and closed it 1.4 minutes after the fix went live. The evidence, the reasoning and the timeline stay attached to the incident.
The same fault was drilled on 1 October with the same result: caught in 1.91 minutes, closed 1.71 minutes after the fix. An earlier attempt that morning measured nothing, because Sentinel itself had stopped completing checks for about 13 hours. That outage is counted against it on its reliability page, which reads day 7 of a 30-day measurement, watching 91.1% of the time against the 95% it needs.