Running & Maintaining a Site

Incident Response

Definition

Incident response is the handling of an unplanned interruption: the site is down, a page is wrong, a certificate has expired, a file is serving to the wrong people. The sequence is always the same shape — detect, assess, communicate, mitigate, fix, review. Mitigate comes before fix deliberately, because restoring service and finding the root cause are different jobs and doing them in the wrong order lengthens the outage. Larger teams add roles, so that one person runs the incident and another writes the updates. For a one-person site the whole thing can fit on an index card, and it still helps, because the first ten minutes of an outage are when judgement is worst.

Why It Matters

Most of the damage in a small outage comes from flailing. Someone starts editing live files to test a theory, a second person deploys a fix on top of the first, and the site ends up in a state nobody can describe. A rehearsed response stops that: roll back first, then investigate on a copy. The difference shows up in minutes — a rollback is typically under a minute, while diagnosing a broken build under pressure can easily run past an hour. The review afterwards is what stops the same incident happening a third time, and it needs to be a paragraph about the missing check rather than a paragraph about who typed the wrong thing.

How It Works

Write down the trigger: what counts as an incident, usually two failed checks from your monitor or a report from a real person. Name the first action for each common case — for a static site, restoring the previous version is almost always it, because instant rollback returns a known-good state without needing to know what went wrong. Post the first note publicly within ten minutes, with what is affected and when the next update will come. Keep a running timeline in one place as you go, with timestamps, because you will not reconstruct it afterwards and the deployment log will only tell you half of it. When service is restored, say so explicitly, then hold the review within a few days and turn each finding into one concrete change: a new smoke test, an earlier certificate alert, a second person with the registrar login.

Real-World Example

A course provider publishes its handbook and worksheets at fernway-course.99helpers.site. On a Thursday a bulk upload replaces the stylesheet with an empty file and every page renders as unstyled text. The monitor's keyword check fires at 14:02. At 14:04 the owner rolls back to the previous version rather than hunting for the bad file, and the site is correct again at 14:05. The investigation happens afterwards on a local copy, and the review produces a single change: uploads now go to a staging address first, where a two-minute check would have caught it.

Common Mistakes

  • Debugging on the live site before restoring it — every minute spent understanding the fault is a minute the visitors are still seeing it
  • Saying nothing until the cause is known, which leaves customers guessing for the entire period when reassurance is cheapest
  • Two people fixing at once with no coordination, so a rollback and a new upload collide and the site ends up in a third, unfamiliar state
  • Skipping the review because the outage was short — short incidents are usually the cheap rehearsal for the long one

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 →