Why a website incident needs a written response
When a business website goes down, displays unfamiliar content, or starts sending unexpected alerts, people naturally want to fix it immediately. That urgency is understandable. It can also lead to rushed changes: someone resets several passwords without recording what happened, a plugin is removed before its logs are checked, or a public explanation is posted before the facts are clear.
A short incident runbook gives a small team a calmer starting point. It is not a thick policy manual or a promise that every outage will be painless. It is a one- or two-page guide that says who takes the lead, what to check first, who can approve changes, and how the business will know the site is safe enough to return to normal.
This is useful for ordinary operational problems as well as potential security events. A failed update, expired domain setting, broken checkout form, suspicious administrator account, or malware warning each calls for a slightly different technical response. The basic operating pattern is the same: stabilize the situation, gather enough information to make a decision, recover carefully, and record what should change next time.
Start with a small set of incident triggers
Do not try to predict every possible website failure. Begin with the events that would materially affect customers, revenue, or the company’s reputation. For many small businesses, that short list includes the site being unavailable, contact or checkout forms failing, unexpected website changes, a suspected account takeover, a hosting or domain notification, and a credible report from a customer that the site is behaving strangely.
Write each trigger in plain language. For example: “The homepage or contact form is unavailable to more than one person” is more actionable than “website problem.” The runbook should also say how to confirm the report. Test from a second browser or network, use a known monitoring alert if one exists, and capture the exact page, time, and error message. This avoids treating a single local connection issue as a site-wide event.
Assign roles before there is pressure
Small businesses rarely have a dedicated incident-response team. That is fine, provided responsibilities are clear. Name a business owner or operations lead who can decide on customer communication and business priorities. Name a technical contact—an internal administrator, web developer, hosting provider, or managed service partner—who can investigate and make approved changes. Include one backup contact for each role.
Record the contact methods in a secure location that remains available if the website or company email is affected. The runbook should identify where domain, hosting, WordPress, DNS, backup, and monitoring access are held, but it should never contain passwords or recovery codes. Instead, point to the approved password manager entry and name the person authorized to use it.
Decide who may take disruptive actions. Restoring a backup, placing the site in maintenance mode, changing DNS, disabling a plugin, or rotating credentials can all have customer impact. A simple rule such as “the technical lead recommends the change; the operations lead approves it unless immediate containment is necessary” prevents confusion without slowing every response.
Use a first-hour checklist that protects evidence and customers
The first section of the runbook should be a checklist, not an essay. Start a time-stamped incident note. Record who reported the issue, what is affected, what has been observed, and every action taken. Screenshots of visible errors and copies of relevant alerts can be useful. If compromise is suspected, avoid casually deleting users, files, or logs before the technical contact has assessed them; those records may explain how the problem occurred.
Next, limit harm in proportion to the risk. For a suspected administrator-account compromise, the appropriate first step may be to disable that account or restrict privileged access. For a site-wide outage, the immediate step may be to confirm hosting status and show a simple maintenance message if the site is unstable. Do not automatically make broad changes because one alert appeared. Verify the scope, then take the smallest reversible action that reduces exposure.
Keep customer communication factual and useful. If customers need to know, say what service is affected, what they should do in the meantime, and when the next update will be provided. Do not speculate about the cause, promise a restoration time that has not been confirmed, or disclose technical details that could create additional risk. A prepared message template helps the business communicate without inventing language under pressure.
Make recovery a controlled decision
Recovery is more than getting the homepage to load. Before restoring a backup or re-enabling a component, identify the recovery point, its date and time, and what data or changes might be missing. Confirm that the backup source is expected and that the restore plan will not overwrite newer information without approval. For a WordPress site, the plan may need to address both files and the database, along with themes, plugins, and configuration settings.
After the technical change, test the journeys that matter: the main pages, contact form, checkout or booking flow if applicable, administrator login, and automated email notifications. Test as a normal visitor as well as an administrator. Watch for a short period after recovery, because a site can appear healthy while a form, integration, or scheduled task is still failing.
Document the decision to return to normal operations: who approved it, what was tested, and any remaining limitations. This record is useful when someone asks what happened later, but it is also the seed of a better runbook.
Review the runbook after every real event and one planned test
When the immediate work is over, hold a short review. Ask what was detected first, what information was missing, which contact or access step caused delay, and what one or two improvements would reduce friction next time. Keep the result practical. The answer might be a current hosting contact, a tested backup restore, fewer administrator accounts, a better uptime alert, or a clearer customer-update template.
Run through the document at least once when there is no incident. A fifteen-minute tabletop exercise—“the contact form has stopped delivering messages; what do we do first?”—will expose stale phone numbers and vague instructions safely. Update the date at the top so the team knows it has been reviewed.
A good runbook does not replace a capable technical partner or strong website maintenance. It gives the business a dependable way to bring the right people together, make smaller decisions with better information, and recover without turning a stressful problem into a guessing game.
Next step: Contact Code Etcetera to review whether your current systems are ready for practical automation.