Release checks: prove the critical route and prepare a rollback

Case study

A case portal build passes locally, but deployment points the case API to the wrong route. The home page responds 200, while the case endpoint responds 404. A post-release check catches the mismatch before the rollout expands. The operator restores the prior application version and investigates the route mapping. If the new release also changed stored data in a way the prior version cannot read, a code rollback alone is insufficient; migration and compatibility planning have to precede the release. The check is deliberately read-only and makes no claim about every user journey.

Working contract

async function verifyRelease(baseLocation) {
  const pageTarget = new URL("/cases/47", baseLocation);
  const apiTarget = new URL("/api/cases/47", baseLocation);
  const [page, api] = await Promise.all([fetch(pageTarget), fetch(apiTarget)]);
  if (page.status !== 200 || api.status !== 200) {
    throw new Error(`Route failure: page ${page.status}, API ${api.status}`);
  }
  if (!page.headers.get("content-type")?.includes("text/html")) {
    throw new Error("Case page returned the wrong content type");
  }
  const markup = await page.text();
  if (!markup.includes("Case 47")) throw new Error("Case landmark is missing");
  return true;
}
const baseLocation = process.env.RELEASE_BASE_LOCATION;
if (!baseLocation) throw new Error("Set RELEASE_BASE_LOCATION");
verifyRelease(baseLocation).then(() => console.log("Read paths verified"));

Cost and tradeoffs

Two network reads take O(R) time for response bytes R plus network latency, and this script retains O(R) response text for the page. More probes improve coverage but increase deploy time and can create load. Keep the first gate small, deterministic, and tied to the most important path; run broader end-to-end checks in a separate stage. A 200 response can still contain the wrong page, which is why the script checks a landmark as well as status. Monitor errors after rollout because a point-in-time smoke check cannot detect later failures or traffic-specific bugs.

Common Mistakes

• Do not treat a green build as proof that deployment routes are correct.
• Do not let a smoke test perform a real customer write without safe isolation.
• Do not assume code rollback reverses an incompatible data migration.
• Do not check only status 200 when the response may be the wrong page.

Continue through the stack

HTTP requests: keep method, status, and body contracts separate; Page performance: budget the critical path and reserve layout space; DevOps: delivery, infrastructure, and reliable operations.

Broader connections

Continuous Integration and Release Gates; Backup and Restore Drills.

Failure trace

The homepage passes a smoke check, but a nested case URL returns a server 404 after deployment. A new database migration also makes the old application binary unusable, so a code rollback cannot restore service. Smoke-check a direct critical route and an authorized data path, and prove schema compatibility before release. A rollback plan must match the actual state already written.

Verification

• Request a nested page directly in a clean session after deployment.
• Run one authenticated read and a controlled write against the released service.
• Start the previous binary against the migrated schema in staging before calling rollback ready.

Decision note

A smoke check is intentionally small and fast. It catches obvious route and contract failures; broader accessibility, performance, and data recovery require separate gates and drills.

Further connections

Incident Containment and Evidence Timeline.

Further connections

Feature Release and Experiment Controls; Feature Flag Evaluation Scope and Safe Default; Gradual Rollout, Kill Switch, and State Compatibility.