Incident Response When You Are the Whole Team

Large companies have incident commanders, rotations, and a channel that fills with people who know things. You have a phone, an alert, and a rising heart rate.

The interesting part is that the fundamentals of incident response were never about headcount. They exist because humans reason badly under stress — we anchor on the first theory, we skip verification, and we start making changes before we understand what changed. A team of one is more exposed to all three, not less.

So the process below is not a scaled-down version of a corporate playbook. It is the small subset that survives when there is nobody to hand things to.

First five minutes: stop the bleeding, do not solve the mystery

The instinct is to find the cause. Resist it. The first goal is to make the app work again, even in a degraded state, and understanding why can wait until customers are unblocked.

In order:

Confirm it is real and scoped. Load the app yourself from a different network or device. Is it everything, one page, or one customer? "The whole app is down" and "one endpoint 500s for users in one plan" lead to completely different next moves.

Check what changed. Well over half of incidents are caused by a change: your deploy, a migration, a config edit, a dependency update, a provider's release. Look at the last deploy time and compare it to when errors started. If those two are close, you have your answer and you do not need any further theory.

Roll back. If a recent change lines up, revert it before analyzing it. A rollback takes a minute, an investigation takes an hour, and the customer experience of those two is not comparable. You can study the broken version later, at your desk, in daylight.

If nothing changed on your side, check your dependencies. Status pages for your host, database, auth provider, payment processor, and model API. An outage you cannot fix is still enormously valuable to identify, because it converts panic into a communication task.

Then, and only then, start diagnosing. With a request ID from a failing request and structured logs, this is where a good logging setup turns twenty minutes of guessing into one query.

Know your rollback before you need it

Almost everything that makes an outage survivable is decided on a calm afternoon, not during the incident. The single highest-value item is the answer to: how, exactly, do I get back to the last version that worked, and how long does it take?

For a platform like Vercel it may be one click on a previous deployment. For a container host it is re-deploying a previous image tag. Whatever it is, do it once when nothing is wrong, time it, and write the steps down. A rollback path you have never exercised is a hypothesis.

The database is the part that does not roll back cleanly, and it deserves separate thought. Deploying code is reversible; a migration that dropped a column is not. Write migrations to be backwards-compatible with the previous release — add columns before you use them, stop writing to a column one release before you drop it — so that reverting the code never strands the schema. When it does go wrong anyway, the recovery paths are covered in what to do when a migration breaks your data.

And verify your backups by restoring one. An untested backup is a strongly held belief.

A severity scale for a team of one

Severity is not about how bad you feel. It is about what you are allowed to skip.

Deciding this in advance is what lets you go back to sleep for a Sev 3. Without a scale, every alert feels like a Sev 1, and the cost of that is not one bad night — it is the erosion that eventually makes you mute alerts entirely. Which alerts should reach you at all is a design decision covered in monitoring and alerts for a small SaaS.

Say something before you know anything

Customers forgive outages. What they hold against you is silence, and the discovery that you knew and did not say.

Post within about thirty minutes of confirming a real incident, even if the message is "we are aware that checkout is failing, we are investigating, next update in 30 minutes." Then keep that promise — an update at the interval you named, even when the update is "still working on it."

Three things to avoid. Do not guess at a cause in public, because the correction is worse than the delay. Do not give a fix ETA you are not confident in; commit to a next-update time instead. Do not go quiet after resolving — the last message should say it is fixed, what it affected, and whether anything customers submitted was lost.

A hosted status page is worth the small monthly cost the first time you use it, mostly because it is a place to point people that is not your inbox. Keep a short email template ready for the customers who were directly affected, since a personal note after a payment failure retains more goodwill than any credit you could issue.

Write the 30-minute postmortem

Once it is over, spend half an hour writing down: what happened, when it started, when you noticed, what you did, and what would have prevented it. No blame section required — there is nobody to blame but you, and self-flagellation is not an action item.

The valuable output is one or two concrete changes. Usually they fall into three buckets: something that would have caught it sooner (an alert on the symptom, a synthetic check on that path), something that would have made recovery faster (a documented rollback, a feature flag around the risky path), or something that would have prevented it (a test, a constraint, a check in the pipeline).

Do the first item that week, while the memory is doing the arguing for you. The compounding effect here is real: most small products have a handful of recurring failure shapes, and three or four postmortems acted on will remove most of them. Adding automated checks so a bad change never reaches production is the highest-leverage version of that, which is why a check in the deploy pipeline tends to be the action item that comes out of these documents most often.

Keep them all in one file in the repository. When you eventually hire, that file is the most honest onboarding document you own — a companion to your handover documentation.

The calm-afternoon checklist

Everything here takes under two hours total and disproportionately changes how an incident goes:

• Written rollback steps for code and for configuration, tested once.
• A restore from backup, performed at least once, with the time it took recorded.
• A one-page list of every provider you depend on, with status page URLs and support contacts.
• Your access to everything from a phone: hosting dashboard, database, DNS, email provider. Locked-out-at-2am is a genuinely common incident amplifier.
• Recovery codes for two-factor auth stored somewhere that is not the laptop you might be away from.
• A feature flag mechanism for anything risky, so disabling a feature does not require a deploy. Feature flags for small teams covers a version of this that does not need a platform.
• A short note on who else could help — a contractor, a friend with production access, an agency on retainer — because "there is nobody" is a choice, and a phone number in that file is worth a great deal at 2am.

Frequently asked questions

What if I genuinely cannot fix it? Get to the smallest honest position: roll back to any version that worked, disable the broken feature, or put up a maintenance page with an explanation and an ETA for the next update. A degraded product that tells the truth loses far less than a broken one that pretends. Then get help — this is exactly the situation an emergency engagement exists for.

Should I have a status page before I have many customers? A free one, yes, and mostly for your own benefit: it forces you to write updates in a structured place instead of improvising across email, chat, and social. It also becomes the artifact enterprise buyers ask about later, when they start sending you security questionnaires.

How do I stop the same incident happening twice? Act on exactly one item from each postmortem within a week. Not a plan, not a backlog ticket — a change that shipped. Teams that do this find their incident rate falls sharply within a couple of months, because early-stage products fail in a small number of repeating ways.

---

If your incident process is currently adrenaline and a rollback you have never tested, the gap shows up on the worst possible day. SprintX puts rollback paths, alerting, and recovery runbooks in place for small teams — and takes the pager when you need someone else awake. Tell us what broke last time and we will make the next one shorter.