toolkit

Scenario · Something looks broken

The site is down

“The site is down.” The first thing to run, before guessing at a cause.

"The site is down" is the cheapest possible question to answer, and it should be answered first, before anyone starts guessing at a cause. This checks in seconds whether the home page loads at all and whether the basics a visitor actually needs — navigation, a phone number, a way to book — are present, without saying why if it fails; that's a separate investigation, and this exists purely to confirm whether one is even needed.

What to ask for

Critical-path smoke testCritical-path smoke test across every domain at once.

See it work

A real run of Critical-path smoke test:

FAIL  1 FAIL · 0 REVIEW · 0 BLOCKED · 0 PASS

  FAIL   toolkit-tests.pages.dev
         [error] the home page returned HTTP 200 but rendered only 1 characters of text — effectively blank
         [warn] no <nav> or role="navigation" on the home page — the primary menu may be gone
         [warn] no tel: link on the home page
         [warn] no form or booking widget in the delivered HTML — this check does not run JS, so a script-injected form would not be seen

  report: ./out/critical-path-smoke-test-critical-path-smoke-test.html
  text:   ./out/critical-path-smoke-test-critical-path-smoke-test.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

The cheapest possible question, asked first because it’s the fastest to answer: does the home page load at all, and does it have the basics a visitor actually needs — navigation, a dialable phone number, a way to book or submit a form. No browser, one request, seconds not minutes.

  1. Run the critical-path smoke check against the public URL and keep the timestamped report — the time it ran matters as much as the result if this ends up in an incident record.
  2. Read the first failed path, or the stated blocked condition, precisely. A failed smoke test says the critical path is broken; it does not say whether that’s DNS, the origin, a plugin, or something else entirely — resist inferring a cause from this alone.
  3. [manual] Send the exact failing URL and the evidence to whoever owns that layer — the host, the site, or the application — rather than starting the investigation yourself from a guess.
  4. Rerun the same path after their fix and record whether it now passes or is still blocked.

The cheapest check, run first, for a reason

This is deliberately shallow — one request, no browser — because the value is speed: knowing in seconds whether the site is actually down, before anyone spends real time on a deeper diagnosis that a thirty-second check could have ruled in or out.

What this does not cover

Monitoring, and why. This is a check you run, not a watch that runs itself, so it does not beat the client to the phone — that's what a real monitor would do. It also only reports that the critical path is broken, never why; the cause is a separate investigation.

← All scenarios