Website Emergency Planning: What to Have Ready Before Things Break

Something breaks. It’s 11pm on a Thursday, two weeks before your biggest sale event of the year. Your site is down, your phone is ringing, and nobody in the group chat knows who has the hosting login.

That moment. That scramble. That is not an emergency response. It’s a panic response. And the difference in cost between the two is significant.

Most businesses don’t have an emergency response plan. They have good intentions and a vague sense that the developer will sort it out. What they discover in a crisis is that “the developer will sort it out” only works if you can reach the developer, if the developer has the access they need, and if everyone agrees on what “sorted” looks like. At 11pm, none of that is guaranteed.

Here’s the thing most incident guides miss: the right response depends entirely on which kind of emergency you’re in. Treating every outage the same wastes time, can make the problem worse, and leaves you making decisions under pressure with incomplete information. Before you do anything else, you need to work out what you’re actually dealing with.

The three types of incidents and why they require different responses

1. You broke it

A deploy went wrong. A configuration changed. Someone edited something they shouldn’t have. The site was fine, then someone did something, and now it isn’t.

When this is the cause, the response is: stop, then reverse. The goal is to get back to the last known good state as quickly as possible. If you have a staging environment and a deployment pipeline, this is where that investment pays off. The question to ask is simple: what was the last thing you changed? Whatever that is, undo it.

The mistake people make here is trying to fix forward rather than roll back. They start applying patches under pressure when the fastest path to resolution is going backwards. If you can reverse what just happened, do that first.

2. Something external broke it

Your traffic spiked and the server couldn’t handle it. A third-party payment provider went down. Your hosting platform had an outage. The CDN is misbehaving. In every one of these cases, the cause is outside your codebase.

When this is the cause, the response is: diagnose before you touch anything. This is the scenario where well-intentioned intervention causes secondary problems. Developers start restarting services and scaling servers before confirming the root cause, and end up with a more complicated incident than the one they started with.

The question to ask is: did anything change on our side? If the answer is no, start looking outward. Check your hosting platform’s status page. Check the third-party services you depend on. Check your monitoring tools for traffic anomalies. The fix often isn’t on your end at all.

3. A security incident

Compromised credentials. Unexpected data access. Vulnerable, outdated dependencies. An account that shouldn’t be active still showing activity. This category looks different to the first two and needs to be treated completely differently.

When this is the cause, the response is: contain first, communicate second, clean up third. Do not start deleting things in an attempt to tidy up the problem before you’ve documented what happened. You need a clear picture of what was accessed and when, both for your own understanding and because your professional indemnity insurer and legal team may need it.

If customer data is involved, you likely have notification obligations. In Australia, that means understanding your exposure under the Notifiable Data Breaches scheme. This is not the moment to work that out for the first time.

Four things to have ready before any of this happens

Regardless of which type of incident you’re dealing with, four things need to exist before you’re in one.

An escalation chain with real contact details. Not “call the developer.” The developer’s mobile number, a backup contact if they don’t pick up, and clarity on who makes the call to escalate to the next person. Written down somewhere that isn’t locked inside your email app.

A credentials inventory with verified access. Who can log into the hosting platform? Who has the admin credentials for the application? Who controls DNS? These questions should not be answered during an incident. Run through them now. If the answer to any of them is “I think the developer handles that,” fix it this week.

A defined rollback process. For your own deployments: can you reverse a deploy? How? How long does it take? If you’re not sure, that’s worth a conversation with your developer before peak season, not after. See our framework for deciding when something’s ready to ship.

A communications template. Customers and clients need to hear from you during an outage, and the message needs to go out before you’ve finished diagnosing the problem. Draft that message now: what happened (at a high level), that you’re investigating, and when you’ll next update them. Blank that template into a document and keep it somewhere you can find it in 30 seconds.

The document nobody reads until they need it

Everything above should live in a single, simple document. Not in someone’s head. Not in a Slack thread from six months ago. A plain document, in a shared location, that anyone with a stake in your platform can find.

It doesn’t need to be long. One page covering the three questions: who do we call, what access do we have, and what does “fixed” look like? If you build that document on a quiet Tuesday and keep it current, you’ve done more incident preparation than most businesses your size.

The cost of not having it isn’t just the outage itself. It’s the compounding decisions made badly under pressure, the time spent finding information that should have been findable immediately, and the client relationship that takes a hit because your communications were slow and disorganised.

None of that is the developer’s fault. It’s a business operations problem, and it has a business operations solution.

Running into a site incident and not sure what you’re dealing with? Get in touch. A 30-minute call is usually enough to work out where to start.