A buy button that looked perfect and went nowhere.

Every pixel the same. Only the destination was gone.

The Lab keeps one page that exists only to be broken. It sells nothing, nothing links to it, and search engines are told to ignore it. Its button normally opens a stand-in checkout page on the same site.

For this drill the button's link was changed to href="#" and the page was deployed to production. This is what a visitor saw: a normal page with a normal green button that does nothing when clicked. The page returns 200 and loads quickly, so an uptime monitor stays green. It is the same kind of fault we found by hand on our own sites in September: buy buttons linked to nothing, and buttons opening the wrong product's checkout.

lab.slipperdigital.com/sentinel-drill · while the fault was live

The deploy is reported, the way a pipeline would report it.

As soon as the broken page was live, the drill told Sentinel a release had gone out, marked as seeded: a fault planted on purpose, so it is scored in the reliability measurement and never confused with real drift. A release notice makes Sentinel run the site's most important checks straight away instead of waiting for the next scheduled run.

The screen was captured after the drill, so it already shows the second release too: the fix, deployed a little under two minutes later. Releases marked observed further down are ones nobody reported; Sentinel noticed the pages change between two runs and logged them itself.

Releases · the seeded fault and its fix

A critical incident, before anyone looked.

1.92 minutes after the broken page went live, a new incident sat at the top of the list: Buy link goes nowhere, priority critical, because it is a buying step on a check marked revenue-critical. A Slack alert went out at the same moment.

The seven other open incidents on the list are real and unrelated: page-speed readings on other sites, a cookie-consent finding and a layout shift. They were left exactly as they were for the recording.

Time to incident

1.92 min

Priority

Critical

Detector

Buy link goes nowhere

Alert

Slack, on opening

Incidents · open

What broke, where, after which deploy, and how sure it is.

The incident explains itself in plain language: on desktop and on mobile, the buy control has href="#" and opens nothing. It names the deploy the failure began after, and it is careful about how firmly it says so. The attribution reads "timing only", because the first failing run came right after that release but no changed file in it could be matched to the button. Sentinel states how sure it is rather than sounding certain.

It also links the last time the same fault happened, on 1 October, and how that one was fixed. The "observed changes" panel lists one more difference from the approved reference: our own analytics script, added to the site after that reference was taken. It is not part of the fault, and Sentinel does not blame it; it lists it as something to look at.

Incident · open, with its explanation

Checked twice, against an approved reference.

Nothing becomes an incident on one bad reading. Each finding was reproduced 2 of 2 times, in a fresh browser, before anyone was alerted, because a monitor that cries wolf gets muted within a month.

Each finding sets what was observed (href="#") against what was expected (a working checkout link), with screenshots of the approved reference and of the failing run side by side. They look identical, which is the point: this fault is invisible in a screenshot and only shows up when you check where the button goes. Comparing against an approved reference, not against yesterday's page, also means an intended redesign would not raise the alarm.

Findings · desktop, approved baseline beside the failing run

Closed only after the fix was seen working.

The drill then put the original page back and deployed it, standing in for the engineer who would normally do that. The fix release moved the incident into verification. Nobody pressed "resolve". Sentinel ran the checks again and waited for two healthy runs on each affected viewport: desktop 1 of 2, mobile 1 of 2, desktop 2 of 2, mobile 2 of 2. Only then did it close the incident and send the resolved alert.

The timeline keeps every step with its time and who did it, and the incident keeps its evidence after it closes: an evidence pack can be exported as PDF, HTML or JSON for anyone who needs the record later.

Fix live to closed

1.4 min

Healthy runs needed

2 per viewport

Closed by

Sentinel

Opened to closed

1 min 49 s

Incident · resolved

Timeline · from opened to resolved

Every drill counts toward a public measurement.

Sentinel scores itself against a 30-day exit condition: fewer than one false incident per site per week, and every seeded fault caught within 10 minutes. This drill adds to the second half: 2 of 2 measurable seeded faults caught within 10 minutes.

The same page also shows where Sentinel falls short today. It was watching for 91.1% of the time, below the 95% it needs, because it stopped completing checks for about 13 hours overnight into 1 October. The first drill of the three ran during that outage and is recorded as not measurable rather than dropped. The page says "measuring", day 7 of 30, and the exit condition is not met yet.

Reliability · the 30-day measurement, day 7