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.

[ ] 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.