The 15-Minute Production Readiness Checklist: Metrics, Logs, and Alerts to Set Before Launch

Launch day has a predictable shape. The pull request is merged, the migration ran clean, DNS points at the new environment, and everyone is quietly waiting for the first real request. Then someone asks the question nobody prepared for: how do we know if it is working?

If the answer involves opening a terminal and grepping through a container, you are not ready. Monitoring is not a post-launch project. It is part of the release, the same way the database migration is. The good news is that most of it can be set up in fifteen minutes if you have decided in advance what matters. Here is the checklist worth walking through before you flip the switch.

The Four Golden Signals, Filled In

Every service exposes some version of latency, traffic, errors, and saturation. Most teams already have the dashboards. The problem is that the graphs are populated with whatever was easy to collect rather than what answers questions at 2 a.m. Before launch, make sure each signal has a concrete definition:

• Latency: p50, p95, and p99 per endpoint, measured server-side. Averages hide the pain. If p99 is eight times p50, your slowest users are having a different experience than your charts suggest.
• Traffic: requests per second, broken down by endpoint and by customer tier if you have tiers. A total request rate tells you almost nothing when one noisy client doubles it.
• Errors: 5xx rate separately from 4xx rate. They mean opposite things. A spike in 4xx is usually a client or a bot; a spike in 5xx is you.
• Saturation: the resource closest to its limit. That might be CPU, but on a typical web service it is usually the database connection pool, the thread pool, or a queue depth.

Write the threshold next to each one. "Latency looks high" is not a definition. "p95 above 800ms for five minutes" is something an alert can be built on.

Pick Six Alerts, Not Sixty

The fastest way to destroy an on-call rotation is to page on everything. New services typically need fewer than ten alerts at launch, and most of them should be about symptoms your users would notice, not causes you find interesting. High CPU with healthy latency is not an incident. Failing health checks and rising 5xx rates are.

Page versus ticket

Split your alerts into two piles before you create any of them.

• Pages wake someone up. Reserve these for user-visible breakage: checkout failing, API error rate above a few percent, the service not responding to health checks at all.
• Tickets wait for business hours. Disk trending toward full in two weeks, a slowly climbing error budget burn, a certificate expiring in twenty days.

A useful rule: if the alert fires and the correct response is "look at it tomorrow", it should never have reached a phone.

Logs You Will Be Glad You Kept

Logs are the part of monitoring teams skip until their first outage, then wish they had set up properly. Two decisions matter before launch: what a log line contains, and how long you keep it.

Emit structured logs rather than formatted strings. A JSON object with consistent keys — service, env, level, trace_id, request_id, user_id, duration_ms — turns debugging into a query instead of a regex exercise. Propagate a trace or correlation ID through every hop, including background jobs and outbound calls to third parties. When a customer reports a failed order, you want to search one ID and see the whole story.

Then decide retention in tiers, because paying to store debug logs for a year is wasteful and deleting everything after three days is worse.

• Hot: a week or two, fully searchable, for active debugging.
• Warm: thirty to ninety days, cheaper storage, acceptable query latency.
• Cold: anything you keep for compliance or audit, archived and rarely touched.

One firm rule: never log secrets, tokens, full card numbers, or passwords. Redact at the library level, not by asking developers to remember.

Route Every Alert to a Human

An alert that lands in a channel nobody reads is worse than no alert, because it creates the illusion of coverage. Before launch, confirm three things for each alert: who owns it, where it goes, and what the responder should do first.

1. Assign an owning team. Shared ownership means no ownership.
2. Set a routing rule to that team's on-call schedule, with an escalation path if nobody acknowledges within ten minutes.
3. Attach a runbook link in the alert body. Even three lines — "check the queue depth dashboard, then restart the worker deployment" — beats starting from zero at 3 a.m.
4. Send a test alert through the full path and confirm it reaches a phone. Do this during setup, not during an incident.
5. Add a deploy silence window so routine releases do not page the team.

An alert nobody can act on is not monitoring. It is noise with a pager attached.

The 15-Minute Walkthrough

With those pieces chosen in advance, the actual pre-launch pass is quick. Work through it in order and do not skip the last step.

• Confirm latency, traffic, error, and saturation panels load and show live data from the new environment.
• Verify the health check endpoint returns a meaningful status, not a hardcoded 200.
• Check that logs arrive with trace IDs intact and that one known request can be traced end to end.
• Create the six to ten alerts, with thresholds and owners attached.
• Test the paging path once, end to end.
• Put a link to the dashboard and the runbook in the release notes or the deploy channel.

If a step fails, that is a finding, not a blocker. Fix it, note it, and move on.

The First Hour After Launch

Stay with the dashboards for the first hour. Watch error rate and p95 latency before you watch anything else, and keep the rollback command written down somewhere you can copy and paste without thinking. If something looks wrong, resist the urge to debug in place while users are affected; revert first, investigate after.

When the dust settles, do one short retrospective pass on the monitoring itself. Which alert fired and was useful? Which one was noise? What did you wish you could see that was not on the dashboard? Add that panel, adjust the threshold, and put the whole checklist into the deploy template so the next service gets it for free. That habit, more than any tool, is what keeps launches boring.

Photo: pixelcreatures / Pixabay