Skip to content
Back to Launch & Discoverability

Post-Launch Monitoring

The first 24-72 hours after launch — what to watch, what dashboards to build, and how to distinguish launch-spike noise from real regressions.

Why

The launch spike distorts every metric: error rates jump because of new traffic, signup numbers look great but may be curiosity-driven one-time visitors, and the first bug reports are a noisy mix of real issues and user-error. Without a structured monitoring plan, the team either over-reacts to noise (hotfixing a 'bug' that is actually a feature) or under-reacts to a real regression (a payment failure that only affects 2% of users but is 100% of revenue). Post-launch monitoring defines which metrics are signal vs noise, sets thresholds that account for the traffic spike, and builds the dashboards that let you see the product's true health once the spike settles. The goal is to reach a 'steady state' verdict by T+72h: is the product healthier than before the launch, or not?

When

From T+1h (after launch-day execution stabilizes) through T+72h. Continue enhanced monitoring until metrics return to pre-launch baseline or settle at a new (acceptable) steady state.

How

1. Build a launch dashboard with 4 panels: (a) real-time error rate + 5xx, (b) signup/conversion rate vs target, (c) core-action completion rate, (d) support ticket rate + sentiment
2. Define spike-adjusted thresholds: error rate threshold = baseline × (current_traffic / baseline_traffic) × 1.5, so a 10x traffic spike allows 15x error budget temporarily
3. T+1h to T+4h: watch the dashboard every 30 minutes; log any anomaly in the launch log with timestamp, metric, and hypothesis
4. T+4h to T+24h: watch every 2 hours; separate launch-spike bugs (affecting only new users in first hour) from steady-state bugs (affecting users at T+12h)
5. T+24h: write a 24-hour report — total signups, conversion rate, top 5 bugs, top 5 support questions, error rate trend; compare to launch targets
6. T+48h: check retention of launch-day signups — did they come back? Curiosity signups have D1 retention < 10%, real signups > 30%
7. T+72h: steady-state verdict — if error rate and core-action rate are within 10% of pre-launch baseline, declare launch stable; otherwise, schedule a post-launch hotfix sprint

Example

# Post-Launch Dashboard — ez4code v2.0 (first 72h)

## Panel A: Error rate
T+1h:  0.3% (spike, threshold 1.5%)  → OK
T+12h: 0.08% (settling)               → OK
T+24h: 0.05% (baseline 0.04%)        → OK
T+72h: 0.04% (at baseline)           → STABLE

## Panel B: Signups
Target: 200  Actual: 1,247 (6.2x)
D1 retention: 38% (healthy, > 30% threshold)

## Panel C: Core action (project deploy)
Completion rate: 71% (target 60%)
Median time to first deploy: 4.2 min

## Panel D: Support
Tickets: 23 in 72h (top: "how to connect GitHub")
Sentiment: 89% positive

## 24h Report
Signups 1,247 | Conv 12.4% | Top bug OG-404 (fixed T+3h)
=> LAUNCH STABLE at T+72h

Common Problems

  • ⚠Using pre-launch error thresholds during the spike — a 0.1% threshold that was right at baseline traffic triggers constant false alarms at 10x traffic; adjust thresholds for the spike or you cry wolf and ignore real alerts.
  • ⚠Counting launch-day signups as 'success' without checking D1/D7 retention — 5000 curiosity signups with 2% retention is worse than 500 signups with 40% retention; the metric that matters is retained users, not signup count.
  • ⚠Treating every support ticket as a bug — launch users ask 'how do I X?' questions that are documentation gaps, not code bugs; triage tickets into bug vs doc-gap before hotfixing.
  • ⚠Stopping monitoring at T+24h because 'it looks fine' — a regression that only affects returning users appears at T+48h when the first cohort comes back; 72h is the minimum stable window.

Best Practices

  • ✓Build the launch dashboard before launch day, not during — the dashboard should be ready and showing staging data by T-1 day, so T+0 is 'switch to prod data' not 'build panels under pressure'.
  • ✓Instrument a 'launch cohort' flag on every signup during the first 72h, so you can compare launch-cohort retention to baseline-cohort retention in the following weeks — this is the true measure of launch quality.
  • ✓Set up a dedicated launch-log channel (Slack/Linear) where every anomaly, decision, and fix is timestamped; this becomes the raw material for the post-launch retrospective and prevents 'why did we do X?' amnesia.
  • ✓Schedule the T+72h steady-state review as a calendar event at launch time, not later — without a scheduled review, monitoring drifts back to 'when someone notices' and the steady-state verdict never gets made.