WordPress Incident Response: The Agency Runbook

Responding to one broken site is a support ticket. Responding to fifty is an operations discipline. When you maintain 25–50 sites a month, incidents stop being isolated events and start behaving like a steady background rate: a plugin auto-update breaks a checkout, a host pushes a PHP version bump, a license lapses, a form stops sending. Without a runbook, each one consumes a senior developer for an unpredictable chunk of the day and the client hears about it before you do.

The agencies that stay profitable at scale treat incident response the way SRE teams treat uptime: defined severities, a single owner per incident, pre-written communication, and a post-mortem that feeds back into prevention. The hard part is that a WordPress fleet is heterogeneous — different hosts, builders, plugin stacks, and PHP versions — so your runbook has to be host-neutral and builder-neutral to actually work across the whole portfolio.

Every incident has a clock that starts the moment something breaks and stops the moment you restore it. The most expensive segment of that clock is usually the part before you even know there’s a problem — the gap between failure and detection. If your client emails you that checkout is broken, your detection failed, and you’ve already lost trust before you’ve typed a reply.

Build detection into the fleet so the system tells you first. At minimum, run uptime and HTTP-status monitoring on every site, transaction checks on anything with a checkout or critical form, error-rate alerting, and a daily backup-success report. The aim is for your dashboard to flag a SEV-1 before a human notices. Detection is the cheapest place to invest, because shrinking the time-to-detect shrinks total incident cost more than any heroics during the fix itself.

The first decision in any incident is how big it is, because that decides who you wake up and how fast you move. Standardize three severities so nobody debates it mid-fire.

Write the severity definitions where the whole team can see them and tie each one to a notification path. A SEV-1 should page a human; a SEV-3 should land in a backlog. The fastest way to lose an afternoon is to treat a SEV-3 like a SEV-1.

Containment buys you time and stops the bleeding while you diagnose root cause. Resist the urge to debug live on production. Your containment checklist should be the same on every site in the fleet, regardless of host:

• Snapshot first. Take a backup or filesystem/database snapshot before touching anything, so the incident can’t get worse.
• Roll back the last change. Most WordPress incidents trace to a recent plugin update, theme change, or deploy. Reverting the last known change resolves a large share of them outright.
• Isolate the failing component. Deactivate the suspect plugin, switch to a default theme on staging, or disable the broken integration rather than the whole site.
• Put up a holding state if needed. For a SEV-1 storefront, a clear maintenance notice beats a broken checkout silently losing orders.
• Confirm the blast radius. Check whether the same plugin or update affects other sites in the fleet — one bad plugin release can be ten incidents waiting to happen.

That last point is where fleet thinking pays off. If a plugin version broke one client, query your whole portfolio for that version and get ahead of the other nine before the tickets arrive.

Clients forgive outages; they don’t forgive silence. Pre-write your incident communications so the engineer fixing the problem isn’t also drafting emails. Keep three templates ready: initial acknowledgement, mid-incident update, and resolution summary.

• Acknowledgement: what’s affected, that you’re on it, and when the next update comes.
• Update cadence: for a SEV-1, update every 30–60 minutes even if the message is “still investigating.”
• Resolution: what happened in plain language, what you did, and what you’re changing so it doesn’t recur.

Designate one person as the communications owner per incident, separate from the engineer doing the hands-on work. Splitting those roles is the single highest-leverage move for keeping a SEV-1 calm.

An incident you don’t learn from is an incident you’ll have again. For every SEV-1 and recurring SEV-2, write a short post-mortem within 48 hours while memory is fresh. Keep it blameless — the goal is a better system, not a scapegoat.

• Timeline: when it started, when you detected it, when it was contained, when it was resolved.
• Root cause: the actual technical trigger, not the symptom.
• Detection gap: how long between failure and detection, and how to shrink it.
• Prevention: the concrete change — a staging gate, an update policy, a monitoring check — that stops a repeat.

Track your mean time-to-detect and mean time-to-restore over a quarter. If those numbers don’t fall, your post-mortems aren’t feeding back into prevention. Real-world incident patterns and how agencies tightened them are worth studying in WPOS customer cases before you finalize your own thresholds.

Most of the runbook above is human-directed today, and it should be — a senior operator deciding severity and containment is exactly right. What changes the economics is the layer underneath. WPOS is an AI-native operating system for WordPress that runs site work through a structured execution layer rather than poking at the raw site directly, and it’s independent of any host or builder. That neutrality matters for incident response: your runbook can be identical whether a client sits on managed hosting with Gutenberg or self-hosted with Divi.

Today, that execution layer powers the operational work that prevents incidents in the first place — automated audits that surface drift, ongoing content management, and store operations — across a connected fleet. Deeper host-layer automation like self-healing and automated rollbacks is on the roadmap, not something to assume is doing your incident response for you. Build your runbook around humans first; let the execution layer remove the repetitive toil so your seniors spend their time on the calls that actually need judgment.