Uptime Monitoring Setup Checklist
A step-by-step checklist for setting up checks, alerting, and a status page that a small software team can actually maintain.
Reviewed for 2026, updated September 8, 2026.
Most monitoring setups are built in an afternoon and never revisited, which is how teams end up with a homepage check that stays green while checkout is broken. This checklist walks through the decisions that matter, in the order we make them ourselves: what to check, how to define failure, how often and from where to probe, who gets alerted and after how many misses, and what customers see while you fix it. It follows the structure of our complete guide to uptime monitoring at /guide/, so each line maps to a section you can read for the reasoning.
Work through it once when you set up monitoring, then again after every significant incident. Print it or paste it into your team wiki and tick items off as they are done. If you are unsure about the interval and confirmation settings, our detection time calculator at /tools/check-interval-detection-time/ shows how those two choices combine into a realistic time to alert, and our article on alerting without false alarms at /blog/alerting-without-false-alarms/ explains the trade-offs behind each threshold.
- List every customer-facing endpoint that does real work: login, checkout, search, the public API, and any webhook receivers.
- Add a dedicated health endpoint that touches the database and each critical dependency and reports honestly, not just a static 200.
- Define failure for every check as an expected status code plus a content match or JSON field, not any 2xx response.
- Set a check interval between 1 and 3 minutes for customer-facing targets and a longer interval for internal or low-priority ones.
- Probe from at least three geographically separate locations and declare an outage only when a majority of them agree.
- Add an SSL certificate expiry check that warns at least two weeks before the certificate runs out.
- Add a DNS resolution check for the main domain and every API or app subdomain.
- Add TCP port checks for services that do not speak HTTP, such as mail servers or database proxies.
- Set up heartbeat checks for cron jobs and queue workers so a worker that silently stops becomes a visible failure.
- Build a synthetic transaction for the two or three flows that generate revenue, and accept that it will need updating when the UI changes.
- Require 2 to 3 consecutive failures, or failures from multiple locations, before any alert fires.
- Route alerts in stages: chat channel first, then SMS or phone call, then a second person if the first does not acknowledge.
- Write alert messages that state what failed, since when, from where, and include a direct link to the runbook.
- Turn on recovery notifications so the team knows when to stand down.
- Configure maintenance windows so planned deploys and migrations do not page anyone.
- Write a short runbook for every alert that could wake someone up, even if it is only three lines.
- Host the status page on infrastructure that is independent of the main application so it stays up when you are down.
- Group status page components by customer-facing function (login, API, dashboard) rather than by internal architecture.
- Prepare incident update templates for investigating, identified, monitoring, and resolved states.
- Decide which checks feed the public availability number and keep that definition stable month after month.
- Set an internal SLO (for example 99.9% over 30 days) and an external SLA that is looser than the SLO.
- Confirm every phone number and email in the escalation policy belongs to someone who still works here.
- Put a monthly monitor review on the calendar: is each check still relevant, does its alert reach the right person, and has it earned its place?
- Schedule a quarterly incident rehearsal, walk through detection to status page update, and fix the gaps it reveals.
https://pingcrumb.com/templates/uptime-monitoring-setup-checklist/Use it in your business, share it with your team, or link to it from your own site.
Also from PingCrumb
- Monitor Inventory and Alert Routing Worksheet: One sheet that records every check you run, what counts as failure, how often it runs, where alerts go, and who owns the response.
- Free calculators