Three things, in order. Confirm it is actually down for other people and not just for you. Name one person to lead. Post something honest where customers will look. Everything else, including the fix, comes after those three, because they stop the situation getting worse while you work.
The instinct is to dive straight into diagnosis. That is how a fifteen minute outage becomes a ninety minute one, with four people editing the same thing and nobody talking to customers.
None of this needs a large team. The practices that big engineering organisations use scale down neatly, and a marketing site with two people can run a version of them. Here is the version we use.
Anything that stops a customer doing what they came to do. A site that returns errors is obvious. A site that loads but has a broken checkout, a form that silently fails, or a login that loops is the same thing from the customer's side, and it is far more common.
The useful test is not technical severity. It is whether somebody outside your company is currently having a bad time because of it. A broken contact form on a B2B site is a revenue incident even though every monitoring tool will report the site as up.
Write the definition down before you need it. In the moment, people argue about whether something counts, and that argument costs more than just treating it as an incident would have.
One named person, and not the person with their hands in the code. Google's Site Reliability Engineering book, published by O'Reilly, defines four roles for this: Incident Command, Operational Work, Communication and Planning. The command role holds the high level state of the incident and structures the response, assigning responsibilities as needed.
The book is explicit that this separation is the point. As it puts it, a clear separation of responsibilities allows individuals more autonomy than they might otherwise have, since they need not second guess their colleagues. Only the operations side changes the system. The commander keeps oversight and does not do the technical work.
On a small team one person can hold two roles, but not command and operations at once. The moment your leader starts debugging, nobody is watching the clock, nobody is talking to customers, and nobody notices that the fix has stopped working.
By checking from outside your own network, continuously, from more than one place. Your own browser is the least reliable signal you have, because of caching, your network, and the fact that you are logged in and other people are not.
Monitor the thing that matters rather than the homepage returning a 200. A check that loads a page and asserts that a specific element is present will catch a broken build that a status code check sails past. Our notes on website uptime monitoring cover how to set that up without alert fatigue.
Then make sure the alert reaches a person. An alert that goes to a shared inbox nobody reads at 9pm is not monitoring, it is record keeping. Decide who is contactable and how, and accept that a small team may reasonably decide nobody is on call overnight. That is a legitimate choice as long as it is a choice.
That something is broken, what it affects, and when you will next update them. You do not need a cause. Committing to a next update time is the part that stops the inbox filling up, because it replaces uncertainty with a schedule.
The SRE book gives this its own role for a reason. The communication lead is described as the public face of the incident response task force and issues periodic updates to teams and stakeholders. Doing that badly makes an outage feel longer than it was.
Never guess at a cause publicly. The first theory is wrong often enough that publishing it creates a second problem: correcting yourself while still fixing the first thing. Say what is affected, not why.
Work from the outside in, because the layers fail in roughly that order of likelihood. Start with DNS, since an expired domain or a changed record takes a site down completely and looks like a total failure. Then your CDN or proxy. Then your hosting or build platform. Then the application itself.
Ask what changed, and widen the question. Not just your deploy, but a CMS publish, a DNS change, a certificate expiry, an expired card on the hosting account, or a third party script that started failing. On sites we inherit, an outage caused by something nobody on the team deployed is common enough that we check it early.
Third party scripts deserve special suspicion because they run on every page and change without your involvement. Our piece on third party scripts covers how much of your page you have effectively outsourced.
Change one thing at a time, and write down each thing you tried. Under pressure, teams start making several changes at once, which means that when the site recovers nobody knows why, and the same outage returns next month.
Roll back before you dig, whenever a rollback is available. Getting customers working again is a different goal from understanding the problem, and it comes first. You can investigate a broken build calmly once the old one is serving traffic.
If it runs long, hand over properly. The SRE book is unusually specific here: the outgoing commander should say plainly, you are now the incident commander, okay, and should not disconnect until they get a firm acknowledgment. Vague handoffs are how incidents end up with nobody leading them at 2am.
One page, and no more. Who to call, in what order. Where the hosting, DNS and domain accounts live and who has access. How to roll back. Where to post updates. What counts as an incident. That is genuinely enough for most marketing sites.
The access question is the one that catches people. A surprising number of outages get extended because the only person with the registrar login is on a plane. Make sure at least two people can reach every account that could take the site down, and check that quarterly rather than during an incident.
Keep the plan somewhere that works when your site does not. A page hosted on the site you are trying to fix is not a plan, it is an irony. Our notes on choosing web hosting cover which of these dependencies you actually control.
Write down what happened while it is fresh, and keep blame out of it. The goal is a timeline, a cause, and one or two changes that would have prevented it or shortened it. If the review turns into a search for who to hold responsible, people will start hiding problems, which makes the next outage worse.
Pick the smallest real fix. A monitoring check on the thing that actually broke is usually worth more than a large architectural project that never gets scheduled. One improvement that ships beats five that are discussed.
Then close the loop with anyone who was affected. A short, honest note after the fact buys back more goodwill than the outage cost, and almost nobody sends one.
Write the one page plan this week, while nothing is broken. It takes about half an hour, and the useful part is discovering which accounts only one person can access. That discovery alone usually justifies the exercise.
Then test your monitoring by deliberately breaking something on a staging site and seeing whether the alert reaches a human. If it does not, you do not have monitoring yet. If you want help setting this up, or a review of the failure points on a site you have inherited, we are happy to walk through it with you at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.