When a production website dies, the cost is measured in minutes. Here is the exact sequence a professional rescue follows — and what you can prepare today to make it faster.
Minutes 0–5: Stop making it worse
Do not reinstall, do not "just restore a backup", do not change five things at once. Note what happened right before the break: an update? A deploy? A traffic spike? That detail alone eliminates half the search space.
Minutes 5–15: Triage, not guessing
- Is it the application or the infrastructure? Check a static file, then PHP, then the database.
- Read the actual error log — not the browser console. A 500 with a stack trace is a gift.
- If the site is recoverable and the change was recent, a rollback is a legitimate fix. Ship stability first, root-cause second.
Minutes 15–30: Communicate
A proper incident has a timeline: opened, investigating, identified, fixing, resolved. Not because it looks professional — because it stops the same questions arriving from five directions.
After: The report nobody writes (but should)
Every emergency deserves a short post-mortem: what broke, why, what fixed it, and what prevents a repeat. The difference between a site that goes down twice a year and one that goes down monthly is rarely luck.
Prepare now, thank yourself later
- Keep working credentials in one secure place.
- Know where your error logs are.
- Have a staging copy — or at least a recent backup you have actually tested.
On Backend.ly, an emergency incident gives you priority triage, a live timeline from first look to deployed fix, and a prevention report afterwards. You watch the rescue happen instead of wondering if anyone is working on it.
