Setting up a basic uptime monitor takes five minutes. Setting up uptime monitoring well takes a bit more thought. Here are 10 practices we've seen separate engineering teams with genuine confidence in their monitoring from those who find out about production incidents through Twitter.
1. Monitor from multiple regions simultaneously
A single-region monitor has a critical blind spot: it can't distinguish between your site being down globally and your site being unreachable from one geographic location.
Consider: your site is healthy in the US but a BGP routing issue has made it unreachable from Europe. A single US-based monitor shows green. But half your users are in a 503 loop.
Good uptime monitoring tools check from at least 3-5 geographically distributed regions in parallel. An alert should require confirmation from at least 2 regions — this filters out false positives from regional network blips while catching real outages quickly.
2. Don't just check HTTP 200 — check response content
A 200 status code means the server responded. It doesn't mean the response was correct.
Consider common failure modes that return 200:
- A CDN serving a cached error page
- A maintenance page that a developer forgot to disable
- A database connection pool exhausted — the page loads but the content is empty or wrong
- A deployment that silently broke a critical feature
Add a content check: assert that a specific string appears in the response body. For a homepage, that might be the company name. For an API endpoint, assert that the JSON structure is valid. For a checkout page, assert that the payment form is present.
One string. One assertion. Catches an entire class of partial failures that a status-code-only check misses.
3. Monitor your API endpoints, not just your homepage
Your marketing site and your API are two different things. The homepage going down is bad. Your API going down is catastrophic.
Create monitors for:
- Your main API health endpoint (
GET /healthor/api/health) - Critical API paths used by your mobile or frontend clients
- Authentication endpoints (login/logout/refresh)
- Any webhooks your system sends to third parties
Each of these can fail independently of your homepage. Each should be monitored independently.
4. Set check intervals appropriate to your SLA
Checking every 5 minutes means you could go down at minute 1 and not be alerted until minute 5. For a business with a sub-1-minute MTTR target, that's unacceptable.
Guidelines:
- Production services: Check every 60 seconds
- Critical payment/auth flows: Check every 30 seconds (available on higher-tier plans)
- Staging/internal tools: Every 5 minutes is probably fine
- Cron job monitoring: Match the check period to the job's schedule
Don't use 5-minute intervals as a cost-cutting measure if your users depend on fast incident detection.
5. Route alerts to the right channel for the severity
One common mistake: send all alerts to one email address. This creates alert fatigue and means critical downtime notifications get buried in noise.
A better approach:
- SMS / phone call: Production down alerts only. Something a human should wake up for.
- PagerDuty / on-call system: Any incident requiring immediate human action.
- Slack #incidents: All downtime events for real-time team visibility.
- Slack #monitoring: Lower-severity events — SSL warnings, domain expiry notices, performance degradations.
- Email: Recovery notifications, weekly summaries, SSL warnings with a 30-day horizon.
Most monitoring tools let you configure which event types go to which channels. Take 10 minutes to configure this thoughtfully — it makes a significant difference in how your team responds to incidents.
6. Use consecutive-fail thresholds to prevent false-positive noise
A single failed check doesn't necessarily mean your site is down. It might mean:
- A transient network hiccup between the check server and your site
- A single slow response that hit your timeout threshold
- A momentary spike under load
If your monitor alerts on the first failure, you'll train your team to ignore alerts — which defeats the purpose entirely.
Configure your monitors to alert after 2-3 consecutive failures. This adds at most 60-180 seconds to your time-to-alert for real outages, in exchange for eliminating almost all false positives.
7. Monitor SSL certificates and domain expiry with plenty of lead time
We've covered this in depth in a dedicated SSL certificate monitoring post, but the key points:
- Start alerting at 60 days before expiry — you want time to act, not time to panic
- Validate the full certificate chain, not just the leaf cert
- Monitor domain registration expiry alongside SSL — lapsed domain registrations are just as catastrophic
- Watch for unexpected certificate changes, not just expiry
8. Set up a public status page before your next incident
This one's counterintuitive: set up your status page now, while everything is working, not during an incident when you're scrambling.
Benefits of having a status page before an incident:
- You have time to configure it correctly, add components, and share the URL
- Your team knows where to send users during an outage ("check status.yourapp.com")
- You can add a status badge to your app so users see it before they contact support
- When an incident happens, you just update the existing page — no setup required under pressure
Good status pages have subscriber notifications so users can opt in to email updates during incidents. This converts "where is my stuff?" support tickets into informed users who know you're working on it.
9. Monitor cron jobs and scheduled tasks
Every team has scheduled tasks that matter: backups, report generation, data syncs, cleanup jobs. Almost no team monitors them.
The failure mode is always the same: the job fails silently for weeks until someone notices that a backup is missing, a report wasn't generated, or data is stale. By then the window for easy recovery has often passed.
Use heartbeat monitoring: your job sends a ping to your monitoring tool when it completes. If the ping doesn't arrive in the expected window, you get alerted. One extra line in your script, no false positives, catches every silent failure.
See our guide to cron job monitoring for setup details.
10. Review your monitoring setup quarterly
Monitoring configurations drift. Sites get new endpoints. Old monitors accumulate for decommissioned services. Alert routing gets stale as team members change.
Put a 30-minute "monitoring review" on your engineering team's quarterly calendar. Go through:
- Are all production URLs monitored?
- Are the right people receiving alerts?
- Are any monitors green because the service is healthy, or because nobody set them up?
- Are SSL/domain expiry dates all showing adequate runway?
- Have any decommissioned services accumulated false-positive green monitors?
30 minutes, four times a year. It's a small investment that has saved more than a few teams from a nasty surprise.
Monitoring isn't set-and-forget. The teams with the best uptime records aren't the ones with the most reliable infrastructure — they're the ones who know about problems the fastest and have the right people alerted immediately.