Surviving launch day: a live-ops runbook

Launch day is the one day your monitoring earns its keep. It is also the day you are least capable of thinking clearly, which is why the order of operations should be decided in advance. This is the runbook we actually follow.

Watch the rate, not the count

Raw crash counts climb with concurrency — that is arithmetic, not a regression. The signal is the rate: crashes per session, or crash-free sessions as a percentage. Pick your threshold before launch and write it down, because at 2am you will be tempted to negotiate with it.

Separate new from known

The most valuable alert on launch day is “a signature nobody has ever seen before”, because it almost always means the release did it. Known signatures at higher volume are a capacity story; a brand-new signature is a build story.

Scope before you panic

Before touching anything, get the shape of it: which build, which platform, which environment, which region. A crash that is entirely on one platform is a different fix — and a different decision — from one spread evenly across all of them.

Know your rollback trigger in advance

Auto-scaling buys you minutes; a rollback buys you the weekend. Decide beforehand what forces a rollback — a crash-rate threshold, a new signature above some share of sessions — so the decision is a check against a rule rather than an argument at 3am.

The goal on launch day is not zero incidents. It is that every incident is one you can see, scope and decide on within minutes.