Skip to content
Get it — $19.99
Practical lab

Launch Readiness Lab

Read a demonstration site's release evidence and decide whether it launches. See which capture decides it and why a backup log saying SUCCESS proved nothing.

Fifteen minutes, four decisions. A release summary with six green ticks, the raw evidence behind three of them, and a launch scheduled for 17:00. Decide whether it goes — and then see which single capture should have stopped it, and why "STATUS: SUCCESS" in a backup log established nothing at all.

Declared sample data

The summary, the responses and the logs below are fixtures written for this lab. No real site, agency or backup service is involved. The fixture bundle is a public download.

Evidence

release-summary.md (from the agency, 14:10 today)
# Harbourline Physio — release summary

- [x] Forms: contact form tested, submission received
- [x] Redirects: 38/38 old URLs redirect correctly
- [x] Indexing: robots and sitemap configured
- [x] Backup: nightly backup succeeded (see log)
- [x] Performance: LCP 1.9 s on the homepage
- [x] Rollback: previous version available

Recommendation: GO for 17:00.
GET https://harbourline.example/ on the production host (release candidate, 14:02) — response head
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Harbourline Physio — Physiotherapy in Harbourline</title>
  <meta name="robots" content="noindex,nofollow">
  <link rel="canonical" href="https://harbourline.example/">
  <link rel="sitemap" type="application/xml" href="/sitemap.xml">
</head>
Contact form test — inbox capture (13:48)
From: website@harbourline.example
To: reception@harbourline.example
Subject: New enquiry — RELEASE-TEST-2026-09-17-1348

Name: Release test
Message: RELEASE-TEST-2026-09-17-1348 — please ignore

Received 13:48:41. Marker matches the submission made at 13:48:12.
backup.log (last 3 nights)
2026-09-15 02:00:04 backup job started
2026-09-15 02:00:09 upload complete: 0 bytes (0 files)
2026-09-15 02:00:09 STATUS: SUCCESS
2026-09-16 02:00:03 backup job started
2026-09-16 02:00:08 upload complete: 0 bytes (0 files)
2026-09-16 02:00:08 STATUS: SUCCESS
2026-09-17 02:00:05 backup job started
2026-09-17 02:00:10 upload complete: 0 bytes (0 files)
2026-09-17 02:00:10 STATUS: SUCCESS

Steps

Step 1 — Go or hold?

Read the summary first, then the three pieces of evidence. Make the call you would make with twenty minutes and no one else to ask.

Evidence: release-summary.md (from the agency, 14:10 today), GET https://harbourline.example/ on the production host (release candidate, 14:02) — response head, Contact form test — inbox capture (13:48), backup.log (last 3 nights)

What is your decision?

  1. Go — six checks passed and the form evidence is solid.
  2. Hold — the production homepage is set to noindex,nofollow and the backup has been uploading nothing for three nights. Two of the six ticks are contradicted by their own evidence.
  3. Go, with a note to fix the robots meta tomorrow — indexing takes days anyway.
Answer and explanation

Hold — the production homepage is set to noindex,nofollow and the backup has been uploading nothing for three nights. Two of the six ticks are contradicted by their own evidence.

The summary says 'robots and sitemap configured' — and they are, for staging. The release candidate on the production host carries noindex,nofollow, which is the staging value that was never switched. Launching it tells search engines to drop the site. The backup line is worse: three nights of STATUS: SUCCESS with 0 bytes uploaded. A backup job that succeeds at backing up nothing is the clearest example of why 'the job says success' is not evidence. Hold, fix the setting, verify on the production host, then go.

Step 2 — Which piece of evidence decides it?

If you could show the agency only one capture to justify the hold, which one?

Evidence: GET https://harbourline.example/ on the production host (release candidate, 14:02) — response head, backup.log (last 3 nights), Contact form test — inbox capture (13:48)

Choose one.

  1. The homepage response head on the production host: noindex,nofollow is a launch-stopping fault by itself, and it is a live response — not a template, not a screenshot of settings.
  2. The backup log: zero bytes for three nights.
  3. The form capture: it is the only evidence with a matching marker.
Answer and explanation

The homepage response head on the production host: noindex,nofollow is a launch-stopping fault by itself, and it is a live response — not a template, not a screenshot of settings.

Both faults would each justify a hold, but the noindex is the one that makes launch itself harmful, and it is verifiable in one request by anyone. The backup fault is serious and must be fixed before go, but its consequence arrives later; the noindex's consequence starts at 17:00. The form capture is good evidence — of the form.

Step 3 — What is the next safe action?

The agency accepts the hold. Choose the first thing that happens.

Evidence: GET https://harbourline.example/ on the production host (release candidate, 14:02) — response head

First action:

  1. Change the robots setting on the release branch, deploy to the release candidate, fetch the production-host homepage again, and confirm index,follow in the live response — then look at the backup.
  2. Edit the meta tag directly on the production server so it is fixed before 17:00.
  3. Submit the sitemap to Search Console so Google indexes the site as soon as it is live.
Answer and explanation

Change the robots setting on the release branch, deploy to the release candidate, fetch the production-host homepage again, and confirm index,follow in the live response — then look at the backup.

The fix goes through the same path every other change takes, and the verification is the same request that found the fault. Editing production directly creates a version nobody can reproduce and makes the 'rollback: previous version available' line false as well.

Step 4 — And the backup?

The robots fix is verified. Twelve minutes left.

Evidence: backup.log (last 3 nights)

What does 'STATUS: SUCCESS' establish?

  1. Only that the job ran. With 0 bytes uploaded there is no backup; and even with bytes, nothing is known until a restore has been performed and opened.
  2. That the site is backed up; the byte count is probably a logging quirk.
  3. That there is a backup — and the restore test can wait until after launch.
Answer and explanation

Only that the job ran. With 0 bytes uploaded there is no backup; and even with bytes, nothing is known until a restore has been performed and opened.

Success means the process exited without error. Backup means a restorable copy exists. The log shows the first and disproves the second. The pre-launch step is: take a manual backup now, restore it somewhere, open it, then fix the nightly job's source path.

The corrected version

After: GET https://harbourline.example/ (release candidate, 16:21) — response head
<meta name="robots" content="index,follow">
<link rel="canonical" href="https://harbourline.example/">
After: manual backup and restore (16:40)
16:31 manual backup: upload complete: 148.2 MB (2,114 files)
16:38 restore to scratch host: complete
16:40 opened restored site: homepage 200, 3 service pages 200, media present
16:40 nightly job source path corrected (was /var/www/htmll — typo)
Decision: GO at 17:00, with the nightly job to be re-checked tomorrow.

The summary was not lying; it was written from ticks, not captures. The whole point of a launch checklist that demands evidence per line is that the line 'backup succeeded' cannot be written next to a log that says 0 bytes.

Walkthrough

Four screenshots of this lab, taken from the published page: the start, a deliberately wrong answer, the matching answer, and the corrected version. Every screen is described in the image text.

  1. The lab opens on the scenario, the declared sample data with its download, the starting state, and step 1: the release summary and three pieces of evidence, with a four-option decision.
    1. Step 1 of 4: read the release summary and the evidence, then decide go or hold.
  2. A deliberately wrong choice — Go — has been checked. The feedback box, outlined in red, explains that the homepage head shows noindex,nofollow and the backup log shows zero bytes; the Next button stays hidden.
    2. A wrong decision is explained, not hidden. You can try again; the first answer is what the score records.
  3. The correct choice — Hold — has been checked. The feedback box, outlined in green, explains why, and the Next step button has appeared.
    3. The matching decision unlocks the next step.
  4. The end of the lab: 'The corrected version' with the first-attempt score, the after-state evidence (robots meta now index,follow; a manual backup restored and opened), Save to My Project, Reset, and the links to the guide, the generator and the product.
    4. The corrected version, the score, and where to take it next.
The Claude Code Website Launch System
$19.99 · instant download
Get it