A Simple Website Incident Response Plan

An incident response plan is the difference between a bad hour and a bad week. You do not need an on-call rotation: a one-page plan covering who has access, what to check first, and when to stop and call the host handles most website incident response for a small site. This guide is that page.

This guide focuses on the checks a small-site owner can make safely. It also points out where a host, registrar, email provider, or developer needs to take over. Read how to choose a web host if you need the broader setup, our website down checklist for outage triage in the moment, and our migration guide before changing live infrastructure.

Start your incident response plan with an inventory

Protect the account that can change DNS, billing, and server access first. Use a unique password and multi-factor authentication where it is available. An application update cannot compensate for a stolen control-panel login, and an incident is the worst time to discover who actually holds the keys.

Make a short note with account names, domain names, who can access each, and the last known working time. Do not put passwords or recovery codes in the note. You want enough detail to act quickly without creating a new security risk.

The incident response steps, in order

Keep backups outside the production account and practice a restore before you ever need one. A backup that has never been opened is a hope, not a recovery plan — and a working restore is the step every other decision leans on.

During an incident, use a private browser window or a separate device to check the live site. That removes some of the confusion caused by cookies and cached redirects. If a DNS record is involved, note the TTL and allow the old answer time to expire before assuming a change failed.

Test the result like a visitor

When an incident happens, preserve the evidence, restrict access, and work from a known-good copy. Avoid making a string of unexplained changes that destroy the trail you need to understand the problem.

Test the normal path first, then the part that has the most consequence. For a store, that is checkout. For a form, it is receiving the email. A test should answer one question rather than produce a vague impression.

When to stop and ask for help

Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, time in UTC, exact error, and the changes you made. Include a screenshot when it shows the error, but do not include private keys, passwords, or full payment information.

Let's Encrypt documentation has useful background if certificates are part of your recovery: Let's Encrypt documentation. Use it to understand the terms, then return to the small, reversible next step.

Write a downtime postmortem

After the incident, write a short downtime postmortem: what broke, when it started, what fixed it, and which account owned the setting. Hosting problems repeat because nobody remembers which record was changed or which plugin was disabled last time. A dated postmortem turns the next incident into a lookup instead of an investigation.

Keep the change auditable

Use a short before-and-after record. Write the setting you found, its old value, the exact time you changed it, and the result of the test. If the change has a delay, such as a DNS TTL or a cache expiry, write the time you expect the new answer to be visible. This record is useful even when everything works. A few months later, it tells you why a setting has an unusual value.

Do not confuse an account dashboard with evidence from the live site. A dashboard can show that it accepted a record or a deployment. The visitor still needs to receive the page, email, redirect, or certificate you intended. Test from outside the account, and use a second connection if a cached answer could mislead you.

If you hand the incident to someone else, give them the record rather than a conclusion. "The site is broken" is hard to investigate. "The outage began after this update, affects this URL, and persists in a private window" gives the next person a useful starting point.

One last check

Before you declare the incident over, repeat the action that first failed. Use the ordinary path a visitor or colleague would use, not only the account dashboard. If the result is different, note the difference and keep troubleshooting from that point. A quiet confirmation now is much easier than a second outage announcement.

Leave a useful handoff

Save the postmortem and final test result with the date and accounts involved. If someone else handles the next incident, they should be able to see what happened last time without reconstructing it from browser history.

Bottom line

A small site's incident response plan fits on one page: know who has access, restore from a tested backup, change one thing at a time, and write the postmortem while the details are fresh. Keep evidence, protect your backups, and ask support before a safe step turns into a data-loss risk.

Frequently asked questions

Should I fix everything at once during an incident?

No. Change one related setting, test it, and keep the previous value until you know the result is stable. That discipline is most of what an incident response plan enforces.

What should my plan include for contacting hosting support?

The domain, exact URL or service, UTC time, error text, and steps already tried. That is usually enough for support to find the relevant logs.

Should backups be part of website incident response?

Yes. Download or verify a recent backup before edits that affect files, databases, email, DNS, or software versions — during an incident, the tested backup is your way out.