A first hour triage checklist when a site goes down
Spend the first hour deciding what is broken, not why. Scope is cheap to establish and it eliminates most causes for free; cause hunting on an unscoped fault is how a twenty minute problem turns into an afternoon. The sequence below is time-boxed on purpose. If you reach the sixty minute mark without a working theory, that is not failure, it is the signal to hand the problem to someone with access you do not have.
Minutes 0-10: observe, and change nothing
The strongest instinct at minute one is to fix something. Resist it for ten minutes. Every restart, plugin rollback, cache purge or DNS edit you make before you have looked destroys the evidence that would have told you the answer, and adds a variable you will later have to rule out.
- Write down the clock time you first saw it, and the last time you know it worked.
- Capture the exact symptom text. A blank page, a 500, a 503, a browser certificate warning and a connection timeout are four different faults with four different owners. Status codes are worth reading literally rather than by feel, and the HTTP status reference is the right arbiter.
- List anything that changed in the previous 48 hours: a deploy, an update, a nameserver edit, a certificate or domain date passing, a traffic spike, a payment that failed.
The only permitted actions in this window are ones that copy rather than modify: screenshots, saved response headers, a note of which URL you actually requested.
Minutes 10-25: fix the scope on three axes
Three questions, each with one cheap test. Answer all three before forming any theory.
| Axis | Cheapest test | What the answer buys you |
|---|---|---|
| Breadth: one site, or all of them | Load a second site on the same account or server | Both down points at the account, server or network layer. Only one down means the fault lives inside that site. |
| Audience: everyone, or only you | Load it from a phone on mobile data, and from an external checker | Fine elsewhere means the problem is your resolver, your cached DNS, your browser state, or an address-level block. That is a much smaller search space. |
| Surface: whole site, or one path | Request a static file such as /robots.txt, then a database-backed page |
Static served but dynamic failing puts you in application, PHP or database territory, not in networking. |
Minutes 25-45: one change per test, written down
Keep a plain log with four columns: clock time, what you did, the exact result, what it rules out. It exists for one reason, which is that a person under pressure repeats the same three checks in a loop without noticing. If a line already appears in your log, do not run it again.
- Never make two changes between two tests. If both were in flight you learn nothing from either.
- Revert anything that did not help before you try the next thing, so you finish the hour with the site that broke rather than a modified one.
- Prefer tests that halve the space over tests that confirm a hunch.
Minutes 45-60: decide, then stop
Escalate rather than continue when any of these is true: the fault covers every site on the machine, the symptom is intermittent and you cannot reproduce it on demand, the remedy needs access at the network or node level, or your log shows you circling. Hand over the timeline, the exact errors and the tests you already ran; a ticket that starts from your scope work skips the round of questions that otherwise costs another hour. Open it through contact as soon as the criteria are met, not after one more attempt.
Deeper treatments of host-versus-site attribution, of packaging evidence so a ticket lands well, and of reading browser-side errors are separate pieces in the diagnostics section. This page is only the order of operations for the first hour.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.