Uptime Monitoring Checklist: What to Watch and How to Alert

Cover each layer a customer's request passes through:

• Public website and marketing pages: a simple availability check on the home page.
• Application and login: the app loads and a real sign-in works.
• API health: a lightweight endpoint that checks its own dependencies, such as the database and cache, and reports them honestly.
• Critical flows: signup, checkout or whatever earns your revenue, tested end to end with a synthetic script.
• DNS and TLS: resolution works and certificates aren't about to expire. Certificate expiry is a preventable outage that still catches teams.
• Background jobs and scheduled tasks: heartbeat checks that alert when an expected ping doesn't arrive.
• Third-party dependencies: payment, email and authentication providers that your app cannot work without.

If you can only build three things this week, choose the login flow, the API health check and certificate expiry.

Cheap checks give false confidence, so design them to fail when customers would notice:

1. Verify content, not just a 200 status. An error page or a login wall can return success.
2. Run from more than one region, and require two or more locations to fail before alerting, to filter out a bad network path.
3. Confirm a failure with a quick retry before paging.
4. Set a timeout that matches user tolerance, so a check that takes 30 seconds counts as down.
5. Don't hit expensive or state-changing endpoints often. Use a dedicated health route and a test account.
6. Choose an interval that fits the impact: a minute for the checkout, five minutes for the marketing site.

A short interval multiplied by many locations and many checks can turn into a large monitoring bill, so match tightness to importance.

An alert is only useful if it reaches someone who can fix the problem. Decide these things in advance:

• A named on-call person, with a backup, and a clear escalation time if the first person doesn't acknowledge.
• Channels: phone or push for outages, chat for warnings, email for reports. Don't send everything to one noisy channel.
• Severity: page for customer-facing outages, and ticket for slow degradation that can wait until morning.
• Runbook links inside the alert so the first responder knows where to look.

Track how many alerts are false. If people start muting the channel, fix or delete the noisy monitors immediately, because an ignored alert system is worse than none.

It helps to know what a number means before you promise it. An availability target of 99% allows about 3.65 days of downtime per year, while 99.9% allows about 8.76 hours¹.

Say you run a single database instance with no failover. A four-nines promise would be fragile, because one restart could use much of the year's allowance. Match your target to your architecture, and write down what you promise customers only after you've measured what you deliver.

When something breaks, customers want an acknowledgment and an estimate. Keep a status page, hosted separately from your own infrastructure so it stays up during an outage, and publish incidents promptly with plain updates. Tell customers what you know, what you're doing and when you'll update next.

Maintain the system itself:

• Test your monitors monthly by intentionally breaking a non-production check or pausing a heartbeat.
• Add a monitor for every incident that customers reported first.
• Silence checks during planned maintenance, and remove the silence afterward.
• Review the list quarterly and delete monitors for retired services.

A tool such as Datadog can run synthetic checks alongside your metrics, and the platform comparison covers other choices. The production deployment checklist covers what to watch right after releases.