Monitoring Checklists Work Best When They Are Small

A checklist should change behavior

Monitoring checklists are easy to write and easy to ignore. The useful ones are short, specific, and tied to moments when risk increases: launches, migrations, deploys, certificate changes, domain moves, and major traffic events.

The checklist should answer one question: what needs to be visible before we are comfortable?

Before a launch

A launch checklist should prove that the customer path works and that expiration-based failures are visible.

Start with:

• Homepage or landing page uptime
• Signup, login, or checkout path
• API health endpoint
• SSL expiration and authenticity
• Domain expiration
• Nameserver changes
• Server CPU, memory, and disk
• Status page availability

That is enough to catch the common surprises without pretending the launch can be made risk-free.

Before a migration

Server migrations and DNS changes need checks on both the old and new paths. Monitor the destination before the cutover, then keep checks active after traffic moves.

Useful checks include external uptime, DNS resolution, TLS certificate presentation, application login, database connectivity, background jobs, and error rates. If the migration involves a CDN or reverse proxy, add a check that confirms origin behavior is still correct.

After a deploy

Post-deploy monitoring should focus on the workflows the deploy touched. If a release changed billing, monitor billing. If it changed authentication, monitor authentication. Generic homepage checks are useful, but they rarely catch business logic failures.

Deploy markers help responders connect a new alert to recent change. Even a simple note in the incident timeline can save time.

During an incident review

After an incident, update the checklist with one concrete improvement. Add a missing monitor, adjust a noisy threshold, rename an unclear alert, or connect a service to the status page.

The best monitoring checklist is not long. It is alive.