An incident response plan for a team of one

It’s 2am. Your app is down. You’re the whole team, so there’s nobody to page and nobody to hand it to. Your brain is half-asleep and you’re staring at a terminal trying to remember how to even check if the database is alive.

That’s the worst time to be figuring out your process. A written incident plan turns panic into a checklist you can follow half-conscious.

Why this happens

Solo founders skip incident planning because it feels like enterprise theater. Incident commanders, severity matrices, war rooms: all of that assumes a team. So you tell yourself you’ll just deal with problems as they come.

The problem is that outages are exactly when your judgment is worst. You’re stressed, possibly tired, and every minute of downtime feels like it’s costing you customers. Under that pressure people make things worse: they restart the wrong service, run a destructive command, or spend 20 minutes checking things that were never the problem.

A plan doesn’t need a team. It needs to answer three questions before you’re in the middle of a crisis: How do I know something’s wrong? What do I check, and in what order? How do I tell users? Write those answers down once, when you’re calm, and follow them when you’re not.

How to fix it

Build a one-page runbook. Keep it somewhere you can reach from your phone: a pinned note, a file in your repo, a Notion page. Not buried in a folder you’ll never find at 2am.

Here’s a template you can copy and fill in.

# Incident Runbook: [App Name]

## Step 0: Stay calm, start a timer
Note the time. Write down what you observe in a running log as you go.
You'll need it for the postmortem and for telling users.

## Step 1: Confirm it's real
- [ ] Load the app yourself: https://myapp.com
- [ ] Check the status monitor: https://status.myapp.com (Uptime Kuma)
- [ ] Is it down for everyone or just me? Try a phone on mobile data.

## Step 2: Triage, how bad?
- SEV1: app fully down, or data at risk. Drop everything.
- SEV2: a feature is broken, core app works. Fix today.
- SEV3: cosmetic or minor. Log it, fix this week.

## Step 3: Check the usual suspects, in order
1. Is the server up?        ssh deploy@server "uptime"
2. Is the app process up?   ssh deploy@server "docker compose ps"
3. Is the database up?      ssh deploy@server "docker compose exec db pg_isready"
4. Is the disk full?        ssh deploy@server "df -h"
5. Recent deploy?           check git log / deploy history
6. Recent errors?           check error tracker / logs

## Step 4: Communicate (even a one-liner)
Post to status page + one channel users watch:
"We're aware of an issue affecting [X] and are working on it. Updates here."

## Step 5: Fix, then verify
- Make ONE change at a time. Check after each. No shotgun fixes.
- If you're about to run a destructive command, STOP. Back up first.

## Step 6: All clear
- Confirm the app works from a fresh browser.
- Update the status page: "Resolved."
- Note the end time.

## Step 7: Postmortem (next day, not now)
- What broke, root cause, how you fixed it, how to prevent it.

## Emergency contacts / accounts
- Host (Hetzner) login: [where the credentials live]
- Domain registrar: [...]
- Database backup location: [...]
- Rollback command: [...]

A few things make this template actually work when you need it.

Fill in the real commands for your stack. The template above assumes Docker Compose on a VPS. If you’re on something else, replace the commands with yours and test them once so you know they run. A runbook full of commands you’ve never run is a rumor, not a plan.

Put the destructive-command guardrail in bold. The single most common way a solo founder turns a small outage into a disaster is running DROP, rm -rf, or a bad migration while panicking. The rule “back up before any destructive command” belongs in your runbook because that’s the moment you’ll forget it.

Know your rollback before you need it. The fastest fix for most incidents caused by a deploy is to roll back to the last working version. Write down the exact command. For a Docker setup that’s often redeploying the previous image tag:

# roll back to the previous known-good image
docker compose pull myapp:previous-good-tag
docker compose up -d myapp

Have a status page. You don’t need a fancy service. Uptime Kuma, which you can self-host, gives you both monitoring and a public status page in one tool. When users can see you know about the problem, the support emails slow down and you get room to actually fix it.

The whole thing takes an afternoon to write. You’ll be grateful for every minute of it the first time something breaks at a bad hour.

Or, we do it for you

A named human who already knows your stack is the difference between a 10-minute outage and a 2-hour one. Managed hosting from Stackbastion means the runbook is written, the backups are tested, and someone other than you is on call. Start with a free audit and we’ll tell you where your current setup would hurt most in an incident.

FAQ

Isn’t an incident plan overkill for a small app?

The plan scales to your size. A solo founder’s runbook is one page, not a 40-page enterprise document. The point isn’t process for its own sake, it’s having decisions made in advance so you’re not improvising while your app is down and your judgment is compromised.

Where should I keep the runbook?

Somewhere you can open from your phone in seconds, and that does not depend on your app being up. A pinned note, a Notion page, or a printed sheet all work. Do not keep it only inside the system that might be down during the incident.

What’s the first thing to do when something breaks?

Confirm the problem is real and note the time. A surprising number of “outages” are your own network, a cached error, or a browser issue. Thirty seconds of confirmation stops you from restarting production services to fix a problem that was never there.

Do I really need a postmortem if I’m the only one who’ll read it?

Yes, and keep it short. Writing down the root cause and one prevention step is how the same outage stops happening every month. Future-you, six months from now, will not remember why the database ran out of connections. The note will. For a worked example, see our database connection exhaustion postmortem.