A one-person incident playbook you can actually run in 60 minutes

When you run a SaaS by yourself, an outage does not just break the product. It breaks your day. Customers email, dashboards blink red, and every minute you spend guessing is a minute trust erodes. The fix is not a heroic debug session. It is a short, written-down sequence of moves that you can follow even when your brain is running on caffeine and adrenaline.

This is a grounded 60-minute playbook for solo founders and tiny teams. It assumes you do not have an on-call rotation, a war room, or a security operations center. It assumes you have a laptop, a status page you can edit, and roughly an hour.

The goal is simple: stop the bleed, tell customers what is happening, and leave yourself a clean record of what to fix next week.

What “incident response” actually means at a one-person SaaS

The research is consistent. Incident response is a structured process for identifying, containing, and recovering from disruptions, with the explicit aim of limiting damage and downtime. The frameworks behind it — NIST’s preparation, detection and analysis, containment/eradication/recovery, and post-incident activity, or SANS’s six-step version — were built for large teams, but the shape works for one person too.

For a solo founder, the discipline collapses into four jobs you have to do in the right order:

  • Detect early enough that you catch the outage before your inbox does.
  • Stabilize the system so users can do the most important thing, even if some features are broken.
  • Communicate honestly, twice — once when you notice, once when you have more.
  • Record what happened, in writing, so the next outage starts from a shorter checklist.

Skip any one of those and the outage costs more — in trust, in support tickets, and in the silent churn that follows a bad week.

Pre-game: what to set up before you ever need this

A 60-minute response is only possible if the boring setup is already done. Spend a weekend on these five things so that when something breaks, you are not building the plane mid-flight.

1. A status page you can update from your phone

Pick a hosted status page (most incident-management tools include one, and there are standalone services too). The non-negotiable feature is that you can post an update from a phone browser, not just a desktop. Practice posting a fake incident once. The first time you should try the editor is not during a real outage.

2. Alerts that wake you for the right things

Configure your monitoring tool — uptime checks, error tracking, log-based alerts — to page you on user-facing symptoms, not infrastructure trivia. “API returning 500s for the login route” is a page. “Disk 78% full on a logging volume” is an email for Monday. MTTD (mean time to detect) is the metric that matters most for a one-person team because every other clock starts here.

3. A runbook folder with three documents

Keep three short, plain-text files somewhere you can find them under stress:

  • Architecture map: where the app lives, where the database lives, what is cached, what talks to what.
  • Credential access: how to reach the database, the hosting dashboard, the DNS provider, the payment processor, and the email sender. Store the actual secrets in a password manager, but document the path.
  • Contact list: who you would email or call if you needed help — a developer friend, your hosting support channel, a contractor. Even a list of one is better than an empty list.

4. A backup you have actually restored

Backups you have never tested are wishes. At least once, restore a database snapshot to a scratch environment and confirm the data is real. Document the steps. A restore you have rehearsed takes minutes; one you have not takes hours.

5. A communication template, half-written

Write the first two sentences of three templates now:

  • “We are investigating an issue affecting…”
  • “We have identified the cause and are working on a fix…”
  • “The issue is resolved. Here is what happened…”

Filling in the blanks is faster than writing from scratch while your inbox is on fire.

The first 15 minutes: detect and stabilize

The first quarter of your hour is about stopping the bleeding. Do not try to fix anything yet. Fixing under pressure, without a diagnosis, is how one bug becomes three.

Minute 0–5: Acknowledge and page yourself. When an alert fires, do three things in this order:

  1. Post a one-line “investigating” note on the status page. Even “we are looking into reports of errors” is enough.
  2. Open your runbook folder and the relevant dashboard.
  3. Note the time. Your MTTD clock just started.

Minute 5–10: Confirm it is real. A surprising number of alerts are noisy. Check two independent signals before you commit: error rates in your error tracker, and a real-user report from email or support chat. If only one signal is firing, watch it for five more minutes before paging yourself mentally.

Minute 10–15: Contain, do not cure. Containment means shrinking the blast radius, not rebuilding the system. Options, roughly in order of cost:

  • Roll back the last deploy if the outage started after a release.
  • Fail over to a backup database or read replica if the primary is the suspect.
  • Toggle a feature flag to disable the broken path so the rest of the product still works.
  • Throttle or block the offending traffic at the edge if you are seeing abuse or a runaway loop.

Pick the smallest move that restores the core flow — usually login and one money path. A degraded app that customers can still use is a survivable incident. A totally dark app is a churn event.

Minutes 15–35: communicate and dig

Once the bleeding has slowed, split your attention between two jobs.

Communicate again. Update the status page with a short, specific message:

  • What is broken in user terms (“logins are failing for some users”), not in stack terms.
  • What you are doing about it.
  • When you will post the next update (commit to a window, like “by the top of the hour”).

If you have paying customers who are visibly affected, send a short email. If the outage touches anything regulated — payment data, health data, EU users — note that legal and breach-notification clocks may be starting, and consult the relevant rule rather than improvising.

Diagnose in parallel. Now look at logs, metrics, and recent changes. The dossier sources are emphatic that the point of detection and analysis is to understand what is happening before you start changing things. Useful questions:

  • What changed in the last 24 hours — deploys, config, DNS, certificates, third-party APIs?
  • Is the database healthy, or are you seeing lock waits, replication lag, or connection storms?
  • Is a dependency down — your payment processor, email provider, or a critical API?

Many solo-founder outages are not novel bugs. They are expired certificates, a vendor’s quiet API change, or a database that has finally run out of a resource it has been borrowing for months. Look for the boring cause first.

Minutes 35–55: fix and verify

Apply the smallest change that addresses the diagnosed cause. Then verify it from the outside — not from your logged-in session. A few habits that pay off:

  • Use a private window or a second device to test the actual user flow.
  • Watch the error rate and the p95 latency for ten minutes, not ten seconds.
  • Check the affected user’s account directly if you can do so safely and with an audit trail.

If the fix does not stick, do not keep tweaking. Roll back to the last known-good state and regroup. A clean rollback you can explain is more credible than five frantic half-fixes.

Minutes 55–60: declare and document

When the error rate is back to baseline and a handful of users confirm things look right:

  1. Post the “resolved” update on the status page with a one-sentence summary.
  2. Send a short email to anyone who reported the issue.
  3. Open a new document — your postmortem — and write down the timeline while it is fresh. Five bullets and a few timestamps are enough for now. You will refine it tomorrow.

Close the incident in whatever tracker you use. The MTTR clock stops here.

The postmortem: a small template that prevents the next outage

A postmortem is not an apology and it is not a blame document. It is a short record that turns one bad hour into a cheaper future hour. The point is to identify the root cause and the changes that will keep the same incident from happening again.

A useful solo-founder postmortem fits on one page:

  • Summary. Two sentences: what broke, and who was affected.
  • Timeline. Timestamps for detection, first communication, containment, fix, and resolution.
  • Root cause. One sentence on the actual mechanism, not the symptom. “Login API returned 500s because the session table hit its primary-key ceiling after a long-running migration” beats “login was down.”
  • What went well. The parts of the response that worked — the alert, the rollback, the status page post. Do not skip this.
  • What went badly. The gaps that cost time — the missing alert, the confusing dashboard, the runbook that was out of date.
  • Action items with owners and dates. At most three. Each one should be small enough to ship in a week. If an action item would take a quarter, break it down or drop it.

A useful test: would a future you, reading this cold on a Sunday night, know exactly what to change and how to verify it? If not, the postmortem is not done.

Trade-offs and scope: what to leave out at one-person scale

You will be tempted, after the adrenaline fades, to bolt on an enterprise incident program. Resist the urge to do it all. For a solo founder, the realistic perimeter is:

  • Do adopt: a status page, basic uptime and error monitoring, a tested backup, three runbook documents, and a postmortem habit.
  • Defer until you have staff: a formal on-call rotation, 24/7 follow-the-sun coverage, dedicated security tooling, and tabletop exercises. These are valuable, but they pay off when you have at least two responders and real revenue at risk.
  • Never skip: honest customer communication and the postmortem. These cost nothing and compound.

A useful way to think about it: every dollar of incident tooling should shorten MTTD or MTTR for your actual failure modes. If a tool does not do that, it is shelf-ware.

FAQ

How long should a postmortem take to write? For a one-person team, thirty minutes the day after the incident is plenty. The goal is a useful record, not a document for an auditor.

Do I really need a status page for a tiny SaaS? Yes, partly because it buys you time. Posting “investigating” lets a worried customer stop emailing you while you fix the actual problem. The status page is also a load-bearing communication tool during the fix.

What if I cannot find the root cause in an hour? That is normal. Stabilize, communicate, and document what you know. Mark the root cause as “under investigation” in the postmortem and schedule a follow-up. Not every outage gets a clean answer in one sitting.

Should I email every customer after an outage? For a small list, a short email is high-leverage. For a large list, the status page is usually enough, with email reserved for paying customers who were visibly affected. Avoid sending an apology you cannot back up with a concrete change.

Sources