When the Site Goes Sideways: A One-Page CMS Incident Card for Lean Teams

It's 4:59pm on a Friday. Someone forwards a screenshot: the homepage is showing last month's campaign banner, the news section is throwing a 500, and the contact form has quietly stopped sending. Nobody can remember where the contingency plan lives. Someone says "isn't it in the wiki?" and everyone starts clicking through pages of notes written two years ago by a person who has since left.

That's the moment a one-page incident card earns its keep. Not a 30-page business continuity document. Not a shared drive folder with a hopeful name. One page, printed if necessary, that tells a small UK web team what to do first, who owns what, and when to stop fiddling and roll back.

Why the wiki fails when you need it most

Wikis are fine for reference. They are terrible for pressure. When the site is wobbling and your monitoring tool is sending alerts faster than you can read them, you don't want to navigate a knowledge base. You want a short, blunt set of instructions that assumes your brain is already half-frazzled.

The other problem is ownership. A wiki page can be edited by anyone, which sounds collaborative until you realise nobody is responsible for keeping it current. A one-page incident card is small enough that one person can own it, review it quarterly, and notice when the vendor's support number changes.

What belongs on the card — and what doesn't

Keep it to one side of A4. If it spills over, you're writing a runbook, not an incident card. The card should cover five things:

• Who does what. Names, not just job titles. The person who checks the CMS, the person who talks to the vendor, the person who updates the status page or sends the holding email.
• When to roll back. A small number of clear triggers, agreed in advance, so nobody has to make a heroic judgement call while the clock is ticking.
• How to reach the vendor. The actual support route, including out-of-hours details if you have them, plus your account reference.
• What to tell users. Two or three short holding messages, written in plain English, that can be adapted without a committee meeting.
• Where to log decisions. A simple timestamped note — even in a shared doc — so the post-incident review isn't a memory test.

Leave out the history of the platform, the full architecture diagram, and the aspirational stuff about resilience. Those can live elsewhere. The card is for the first 30 minutes.

Who does what: name names, not job titles

"The web team will respond" is not an instruction. In a team of three, everyone is already busy. The card should say something like: "Priya checks the CMS admin and confirms whether the issue is content, hosting, or the CDN. Tom calls the vendor and owns that conversation. Alex sends the holding message to the comms inbox and updates the status page."

If you're a team of one, name your backup. It might be a colleague in IT, a trusted freelancer, or your managed hosting provider's support desk. The point is to remove the awkward pause where everyone looks at each other.

Rollback rules: decide before you're sweaty

Rolling back is not an admission of failure. It's a controlled move. But it's much easier to do when you've already agreed the triggers.

For example: if a deployment breaks checkout or the contact form for more than 15 minutes during working hours, roll back first and investigate afterwards. If a plugin update causes layout errors on the homepage, roll back and then test in staging. If the issue is isolated to a single content page, fix forward. Write these down. Keep them specific to your site instead of copying a generic list from the internet.

The card should also name who can authorise a rollback. In a lean team, that might be any one of two people. Waiting for a director to finish lunch is not an incident response strategy.

The vendor line: more than a support portal URL

Most CMS vendors have a support portal, a chat widget, and an email address. In an incident, the portal can be the slowest route. The card should include the fastest route you've actually tested, your account or licence reference, and the name of your account manager if you have one.

If you're on a framework like G-Cloud, add the service desk details and any escalation contact you've been given. If your CMS is open source and supported by an agency, put the agency's out-of-hours number on the card. Don't assume the person reading it will know where to look.

What to tell users (and what not to)

Users don't need a blow-by-blow account of your database migration. They need to know whether the thing they came for is working, and what to do instead.

Write two holding messages in advance. One for a partial outage: "Some parts of our website aren't working properly at the moment. We're fixing it and expect to have things back to normal shortly. If you need to contact us urgently, please email [address]." One for a full outage: "Our website is temporarily unavailable. We're working on it now. For urgent enquiries, please call [number] or email [address]."

Keep them short, human, and free of jargon. Store them on the card so nobody has to write from scratch under pressure. And decide in advance who is allowed to publish them — ideally the same person who owns the status update, not a queue of approvers.

Rehearse it in under an hour

You don't need a full disaster recovery exercise. You need a walkthrough.

Book 45 minutes with the people named on the card. Pick a realistic scenario — say, the homepage is showing stale content after a deployment. Walk through the card step by step. Who checks what? Who calls the vendor? Which rollback trigger applies? Who sends the holding message?

You're not testing the technology. You're testing whether the card makes sense to someone who hasn't read it in three months. Expect to find gaps: a phone number that's wrong, a role that's unclear, a step that assumes knowledge nobody has. Fix them the same day.

Then diarise a quarterly review. Ten minutes is enough. Check the vendor contacts, confirm the named people are still in their roles, and make sure the rollback triggers still match how your site is built. A card that's out of date is worse than no card, because it gives you false confidence.

The point isn't perfection

The point is to replace the 4:59pm scramble with a short, familiar set of steps. You won't eliminate incidents. But you can make the first 30 minutes calmer, faster, and less dependent on whoever happens to be online.

One page. Named people. Clear triggers. A tested vendor route. Holding messages ready to go. That's a realistic incident card for a lean UK web team — and it's one you might actually use.