When should I write a launch postmortem?

Write a draft within two weeks of launch while the details are fresh, then revisit it three months later when you have data on retention, reviews, and the long tail. The two-pass approach captures both the visceral lessons and the strategic ones.

Should a game postmortem be public or internal?

Both. Write an internal version with everything (sales numbers, team conflicts, vendor problems) and a public version that omits sensitive details but shares the lessons. Public postmortems build trust with your community and help other developers, but they should never punch down at individuals.

What is the most important section of a launch postmortem?

What you would do differently. The history of what happened is interesting, but only the action items have value for the next launch. Be specific: which decision, what would you change, what does that look like as a process this time. Vague lessons like 'communicate better' are not actionable.

How to Write a Postmortem for a Game Launch

Quick answer: Use a fixed template (Summary, Timeline, What Went Well, What Went Wrong, Lessons, Action Items), gather both the day-of timeline and the long-tail data, get the team to review it before publishing, and write a public version that shares the lessons without punching down at individuals.

A launch postmortem is the document you wish you had written before your last launch. Done well, it captures the lessons that would otherwise be forgotten by the time the next project starts. Done badly, it is a finger-pointing exercise that nobody reads. The difference comes down to structure, honesty, and a commitment to action items that you actually do.

The Two-Pass Approach

The best postmortems are written in two passes.

Pass 1 happens within two weeks of launch. The wounds are fresh, the timeline is intact, and everyone remembers what happened. This pass captures the visceral lessons: the moments of panic, the unexpected decisions, the small heroics, the things you swore you would never do again.

Pass 2 happens three months later. The data is in. You know the long-tail crash rate, the retention curve, the review sentiment, the refund rate, the sales trajectory. This pass captures the strategic lessons: what the launch told you about your audience, your pricing, your marketing, and your roadmap.

Write Pass 1 immediately even if you only have time for a rough version. The details fade fast.

The Template

A good postmortem has a fixed structure. The structure stops it from becoming a single rambling essay and forces you to address each layer.

1. Summary (one paragraph)

What did you launch, when, on which platforms, and how did it go? Honest one-line verdict: launch was a success / launch was rough / launch was a disaster. Save the nuance for later sections.

2. The Numbers

Hard data on the launch. Use whatever metrics matter for your game and audience.

Wishlists at launch:        14,200
Day-1 sales:                3,400 units
Week-1 sales:               7,800 units
Day-1 crash-free rate:      94.1%
Week-1 crash-free rate:     98.7%
Bug reports day 1:          287 (94 unique)
Reviews at +30 days:        92% positive
Refund rate:                3.2%
Median session length:      47 minutes

Numbers anchor the rest of the document. Without them, every claim is opinion. With them, the postmortem can be challenged on facts instead of feelings.

3. Timeline

A chronological log of the launch period — usually starting two weeks before launch and ending two weeks after. Major events, decisions, and incidents in order. Don’t editorialize here; just record what happened.

T-14d  Final RC build submitted to certification
T-10d  Cert returned with 3 minor failures
T-9d   Hotfix RC2 submitted
T-7d   Cert passed
T-3d   Marketing asset for Reddit ad finalized
T-1d   Pre-load enabled
T-0    Launch
T+2h   Crash report spike from Linux build
T+4h   Hotfix 1.0.1 deployed
T+6h   Crash rate back to baseline
T+1d   Day-1 patch live
T+3d   First negative review wave (multiplayer matchmaking)
T+5d   Hotfix 1.0.2 with matchmaking timeout fix

4. What Went Well

Three to seven things that worked. Be specific. “The team was great” is not useful. “The on-call rotation we set up two weeks before launch meant the day-1 crash spike was triaged in 22 minutes” is useful.

Always include this section. Postmortems that only list problems demoralize the team and ignore the successes worth repeating.

5. What Went Wrong

The hardest section to write well. The trap is to either minimize problems (so you learn nothing) or to point fingers (so people get hurt). The middle path: name the failure, not the person.

Bad: “Sara missed a critical bug in the matchmaking code.”

Good: “The matchmaking code path was not covered by the bug bash because the test plan listed it as ‘handled by automated tests,’ but the automated test only covered the happy path.”

Each item should explain what happened, what the impact was, and why it happened — the third part is the most important. Without root causes, your action items will treat symptoms.

6. Lessons

What did you learn that generalizes beyond this specific launch? Lessons should be shorter than “What Went Wrong” and should connect specific events to broader principles. Three or four lessons is plenty.

7. Action Items

This is the section that justifies the postmortem. Each action item must be:

Specific (not “improve testing”)
Owned by a named person
Time-bounded (by next milestone, by next launch, by Q3)
Tracked somewhere you will actually look at again

If an action item does not appear in your team’s task tracker after the postmortem, it does not exist. Move them out of the document and into reality.

Writing the Honest Sections

The honest sections — what went wrong, lessons, action items — are where postmortems either earn their keep or fail entirely. Some rules that help:

Blameless. Assume everyone made the best decision they could with the information they had at the time. The bug exists because of process gaps, not bad people. If you want a culture where future postmortems are honest, this rule is non-negotiable.

Specific. “Communication was a problem” tells you nothing. “The marketing team did not see the day-1 patch notes until 3 hours after launch because the publishing checklist had no step for sending them” tells you exactly what to fix.

Self-critical first. The author of the postmortem should write the first draft of the “what went wrong” section by listing their own mistakes before listing anyone else’s. This sets the tone.

Internal vs. Public Versions

Write both. The internal version contains everything: dollar amounts, team conflicts, vendor failures, individual missteps. It is read only by the team and used to improve internal processes.

The public version omits sensitive details and is written for an audience of other developers and your community. It shares lessons that generalize beyond your specific situation. Public postmortems build credibility with your players and help the broader indie scene.

Never publish a public postmortem that names individuals as having caused problems. Even if the criticism is fair, a public callout is a kind of harm that no lesson is worth.

The Review Pass

Before publishing the internal version, send it to everyone who is named or affected. Give them a week to flag inaccuracies, request softer language, or add context. People should never be surprised to find themselves in a postmortem.

“The postmortem is not the goal. The action items are the goal. If three months later the team has done none of the things the postmortem said it would do, the document was just therapy.”

Related Resources

For the launch checklist that should precede the postmortem, see game release checklist. For the bug bash event that feeds into launch readiness, see how to set up a bug bash event for game launch. For tracking bugs after launch, see how to monitor game stability after launch.

A postmortem you do not act on is worse than no postmortem — it teaches the team that writing them is performative. Do the action items or do not write the document.