Your first production incident at seed stage is going to happen. Probably in the first six months. Probably on a deploy you were sure was safe. The outage itself is not the problem. What defines whether you keep the customer, keep the team’s confidence, and actually learn something is what you do in the 48 hours after it fires.

This is the playbook I give founders when they ask what to do when the alert goes off and they have never done this before. It is deliberately short, because the moment it is needed is not the moment to read a long document.

Three Windows, In Order

The 48 hours after an incident break cleanly into three windows. Each window has one job. Confusing the jobs is the most common and most expensive mistake I watch founders make the first time.

  • First ten minutes: stabilize.
  • First hour: communicate.
  • First day: learn.

Debugging belongs in none of these windows. Debugging is what you do between windows, in parallel, after the thing is stable. Debugging first is the trap.

First Ten Minutes: Stabilize, Do Not Fix

The alert fires. The dashboard turns red. The impulse of every engineer, especially the one who shipped the last change, is to open the logs and start reading. That impulse is wrong for the first ten minutes.

The job in minute zero to minute ten is one question only: how do we get the system back to a known-working state as quickly as possible, without understanding why it broke yet. The answer is almost always one of three moves:

  • Roll back the deploy. If the incident started within an hour of a deploy, this is the first move. A rollback that turns out to be unnecessary is cheap. A fifteen-minute debug session that could have been a two-minute rollback is expensive.
  • Flag off the feature. If a specific feature went live and started misbehaving, and you have a feature flag covering it, flip it. If you do not have a flag covering it, add that to the postmortem’s action items.
  • Pull the bad config or input. If the trigger was a specific customer’s data, a specific job, or a specific config change, isolate it. Pause the queue. Blocklist the input. Buy time.

None of these three fix the root cause. All three stop the bleeding. That is the job of the first ten minutes.

The failure mode here is the “I know what this is” conviction. The engineer who shipped the deploy is sure they know which line it was, dives into the fix, writes a patch, deploys it, and the second patch makes it worse. I have watched this happen three times at three different companies. Rollback first. Debug after. Not the other way around.

First Hour: Say Something, To Someone

Once the system is stable (which is not the same as fixed), the window shifts to communication. For sixty minutes after the alert, the most important work in the company is not the engineering work. It is the saying-something work.

Three audiences, in order of urgency:

  • The customer who filed the ticket. Someone noticed. Someone wrote in. Answering that person within the first hour, in the founder’s or CTO’s own voice, with “we saw it, here is what happened, here is what we did, we will follow up with you after we understand it fully”, is one of the highest-return activities a seed-stage company has access to. It converts an outage into a trust-building moment. Silence converts the same outage into churn.
  • The customers who did not file the ticket. If the incident was user-visible for more than a few minutes, and you have more than a handful of customers, there are people who hit the error, did not write in, and quietly started looking at your competitor’s homepage. A short, honest status page update, or a short email, catches those people before they decide. “We had an incident between 14:03 and 14:21. Here is what happened. Here is what we are doing about it. Reply to this email if you were affected and we will walk through it with you.”
  • Your own team. The engineers who were not on-call want to know what happened. The product and sales people want to know what to tell customers who ask. A fifteen-line internal Slack post, in the first hour, gets everyone on the same page and prevents the game of telephone that otherwise fills the vacuum.

The common objection: “we do not know what happened yet, so we cannot communicate yet.” This is wrong. You can always communicate three things: that it happened, that you saw it, that you are on it. The investigation finishes in the next window. The acknowledgment is this window’s job.

Silence costs more than a half-formed update. Every time.

First Day: Write The Postmortem That Does Not Suck

Twenty-four hours after the alert, the incident is closed, the fix is deployed, and the team is tired. This is the window where most seed-stage companies drop the ball. They do a short retro in standup, name a cause (“the deploy pipeline missed the migration”), and move on.

That is not a postmortem. That is a wave.

A postmortem that is actually worth writing has four pieces, in this order:

  • A real timeline. Alert fired at 14:03. First responder on at 14:05. Rollback initiated at 14:11. Rollback complete at 14:14. Customer email sent at 14:38. Internal Slack update at 14:45. Root cause identified at 16:20. Fix deployed at 17:40. All-clear at 18:00. Specific minutes, not “around that time”. The timeline is what lets a reader understand how the incident actually unfolded, and it is also what makes the next postmortem comparable to this one.
  • A contributing-factors list, not a single root cause. “Human error” is never the root cause. The real list looks like: the migration was not covered by the deploy pipeline’s automated check; the staging environment did not have representative data, so the migration bug did not surface there; the deploy proceeded without a canary step; the alert fired on a derived metric that lagged the real symptom by nine minutes. Four contributing factors. Each one is addressable. The single-root-cause version lets you blame a person and ship nothing. The contributing-factors list forces real changes.
  • Three action items, maximum. One per factor, at most. Each with an owner’s name and a date. If the list is longer than three, you will not do any of them. If it has no owner, it will not happen. If it has no date, it will not happen. “Add a canary step to the deploy pipeline. Owner: Alex. Done by Oct 25.” That is the shape.
  • A short, honest paragraph for customers. Not the full postmortem (customers do not need the Slack timestamps). A hundred-word public version of what happened, what caused it, what you have changed. Posted to the status page or sent as a follow-up email. This is where you close the loop on the first-hour communication.

The postmortem that does not suck takes maybe three hours of writing and gets referenced for the next year. The postmortem that does suck takes thirty minutes and gets referenced never, which is a reasonable signal that it was not worth writing.

What Belongs On The Shelf Before The Incident

Three things that are worth having set up before you need them. Each one makes the three windows above cheaper by a factor of two or more. Set these up when you have one engineer. Do not wait for the first incident to realize you needed them.

  • A rollback button that works and that you have tested. “We can roll back” is a claim. “We rolled back last Thursday as a drill and it took forty-five seconds” is a capability. Test it when nothing is on fire. The first time you rollback should not be mid-incident.
  • A status page, even an empty one. Any of the hosted ones. You will not use it most weeks. The one week you need it, you will not have time to spin one up.
  • A short on-call policy, even if the team is three people. Who gets paged. What tool pages them. How they acknowledge. When they escalate. One page, written down. The alternative is “whoever happens to see the Slack message”, which fails the first time the person who happens to see it is in a dentist’s chair.

The 2026 Version

AI tooling changes what the three windows cost. It does not change which window matters.

In the first ten minutes, AI is not useful. Rollback and feature-flag-off are decisions a human makes in seconds. An LLM in the loop is friction, not help. Skip it in this window.

In the first hour, AI helps with the drafting. A quick prompt against the incident channel’s messages produces a solid first draft of the customer-facing email, the status page update, and the internal Slack post. The human edits for voice and for anything the model got wrong, which is usually one or two things. The round-trip cost of the first-hour communication drops from thirty minutes to five. This is a real win. The call about whether to communicate and what to acknowledge is still a human call. The drafting is cheap now.

In the first day, AI helps with the mechanical parts of the postmortem. Timeline reconstruction from a Slack channel plus the alert history is a thing an LLM is genuinely good at. Summarizing a long debug conversation into a contributing-factors candidate list, same. Drafting the public paragraph for customers, same. What AI is bad at, and what matters most, is picking which three action items are actually worth doing, and which engineer should own which. That is a judgment call that depends on who the team is, what else is in flight, and what the strategic priorities are. The LLM cannot know those things. You can.

The pattern across all three windows is the same: AI makes the mechanical, text-generation parts of incident response cheap. It makes the human-judgment parts even more important, because those are now the only parts left where the quality of the work depends on the quality of the person doing it.

The Short Version

First ten minutes: stabilize, do not fix. Rollback, flag off, pull the input. Debug later.

First hour: say something, to someone. The customer who complained. The customers who did not. Your team. In that order.

First day: write the postmortem that does not suck. Real timeline. Contributing factors, not a single cause. Three action items with owners and dates. A hundred-word customer version.

Before any of this: a tested rollback, a status page, a one-page on-call policy. Set them up when nothing is on fire.

Let’s Talk

If you are a founder about to have your first production incident, or you just had one and want a second opinion on the postmortem before you share it with the team or customers, that is exactly the kind of thing I work through with founders. No pitch. Happy to look at the specific shape of what happened and tell you what I would do. Reach out.