Running & Maintaining a Site

Smoke Test

Definition

The name comes from hardware: power the board up and see whether smoke comes out. For a website the equivalent is a fixed, short list of checks run against the live address immediately after a change. Five to ten items is right; twenty means nobody will do it. The test is deliberately shallow — it asks whether the site is fundamentally alive, not whether every link in the footer is correct. What makes it valuable is that it is the same list every time, run in the same order, so a result can be compared with the last one. A smoke test is also the natural thing to automate first, because each item is a request with a yes or no answer.

Why It Matters

The failures that hurt most are the ones nobody would believe: an empty homepage, a stylesheet that did not upload, a link to a PDF that now returns 404, a form that silently posts nowhere. These are not subtle bugs, and every one of them is caught by a two-minute list. Consider the arithmetic — two minutes after each publish against an average of 40 minutes to notice and repair a broken live page, and the test pays for itself the first time it fires. It also removes the worst version of testing, which is checking only the page you happened to change and assuming the rest is unaffected.

How It Works

Write the list once and keep it with the site. A reasonable one for a static site: load the homepage and confirm a specific phrase is present, open two deep pages including the most-linked one, request one image and one PDF directly, check the 404 page returns a genuine 404 rather than a soft 404, confirm the address redirects to HTTPS and the certificate is valid, and load the homepage once at phone width. Run it against the production URL after every publish, not against staging, and force a hard refresh so you are not reading your own cache. Automate what you can — a short script that fetches a dozen URLs and asserts the status code and a string in each takes an afternoon to write and then runs on every deploy. When an incident later reveals something the list would have caught, add that check; the list should grow slowly and only from real failures.

Real-World Example

A publisher releases a quarterly report at ashmore-quarterly.99helpers.site, with the PDF as the single most important link on the page. Their smoke test is six lines: homepage contains the report title, both chapter pages load, the PDF returns 200 and a Content-Type of application/pdf, a nonsense URL returns 404, and the page renders at 390 pixels wide. In the July release the PDF had been uploaded with the previous quarter's filename, so the link returned 404 while the page looked perfect. The check caught it four minutes after publishing, before the announcement email went out.

Common Mistakes

  • Checking only the page that was changed — the publish that broke the homepage usually touched something else entirely
  • Testing in a browser tab that has the old version cached, which returns a confident pass on a site that is actually broken
  • Letting the list grow into a full regression suite, at which point it stops being run after every publish and starts being run never
  • Running it against staging rather than the live address, which skips the parts that only exist in production: the domain, the certificate and the edge cache

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →