How to Monitor Website Uptime: A Practical Guide

Your site goes down at 3 AM. You don't find out until a customer tweets about it at 9 AM. Six hours of lost revenue, lost trust, and a scramble to figure out what happened.

Uptime monitoring is the simplest form of observability, and the most neglected. Here's how to set it up properly — from basic health checks to production-grade alerting.

#What uptime monitoring actually does

At its core, uptime monitoring answers one question: is my site responding? A monitoring service sends an HTTP request to your URL on a schedule and records whether the response was successful (HTTP 2xx/3xx) or failed (timeout, 5xx, connection refused).

But "up" is a spectrum. A site can be:

• Completely down — connection refused, DNS failure, timeout
• Partially broken — returns 200 but serves a 503 error page
• Slow — returns 200 but takes 30 seconds
• Intermittent — works sometimes, fails other times

Good monitoring checks all four.

#The three levels of uptime monitoring

#Level 1: HTTP health checks

The simplest check — send a GET request, expect HTTP 200.

# Basic health check
curl -o /dev/null -s -w "%{http_code}" https://your-site.com/health

Most monitoring services do this. Set the interval to 60 seconds for production. Alert when 2+ consecutive checks fail to reduce false positives from network blips.

What to monitor:

• HTTP status code (expect 200)
• Response time (alert if greater than 5 seconds)
• SSL certificate expiry (alert if less than 30 days)

#Level 2: Multi-location checks

A single monitoring location can't distinguish between "your site is down" and "the monitor's network is broken." Multi-location checks send requests from 3+ geographic regions and only alert when the majority confirm the failure.

This is critical for:

• False positive reduction — one location fails means a network issue; all locations fail means a real outage
• Regional detection — your CDN might be down in Europe but fine in the US
• DNS resolution — different locations may resolve to different IPs

Recommended: minimum 3 monitoring locations (US East, EU West, Asia Pacific).

#Level 3: Synthetic monitoring

Synthetic monitoring goes beyond "does it respond?" to "does it work?" It simulates a user journey — logging in, searching, adding to cart, checking out — and alerts when any step fails.

This catches:

• Application errors — the homepage loads but the login form is broken
• Database issues — pages load but data is stale or missing
• Third-party failures — Stripe webhook is down, auth provider unreachable

#Setting up proper alerting

Monitoring without alerting is just logging. Here's how to make alerts useful.

#Alert channels

• Email — best for non-urgent summaries and daily reports. Latency: 1-5 minutes.
• Slack / Discord — best for team visibility and fast triage. Latency: seconds.
• SMS / phone — best for critical services where every minute of downtime costs money.
• Webhook — for custom integrations (PagerDuty, Opsgenie, your own incident system).

#Alert rules

#Alert fatigue is real

The fastest way to make monitoring useless is to alert on everything. Tune your thresholds. A site that returns HTTP 200 with a 200ms response time should never page someone at 3 AM.

Rule of thumb: if your team ignores more than 10% of alerts, your thresholds are too aggressive.

#What to monitor beyond HTTP

HTTP health checks cover the basics, but production sites need more:

#DNS resolution

Your domain might resolve fine in New York but fail in Tokyo. Monitor DNS resolution separately — a DNS provider outage can take down your site even if the server is running.

# Check DNS resolution time
dig your-site.com | grep "Query time"

#SSL certificate

An expired certificate means browsers show a scary warning (or refuse to load the site entirely). Monitor:

• Days until expiry (alert at 30, critical at 7)
• Certificate chain validity
• OCSP stapling status

The Let's Encrypt recommended renewal is 60 days before expiry with auto-renewal.

#Port availability

If you run non-HTTP services (database, Redis, SMTP), monitor those ports too:

# Check if port 5432 (PostgreSQL) is open
nc -zv database-server 5432

#External dependencies

Your site might be "up" but broken because a third party is down:

• Auth provider (Google, GitHub OAuth)
• Payment processor (Stripe, Polar)
• Email service (Resend, SendGrid)
• CDN (Cloudflare, Vercel)

Monitor these endpoints independently so you can distinguish "our code broke" from "our dependency is down."

#Building an uptime dashboard

A good uptime dashboard answers three questions at a glance:

1. Is anything broken right now? — Color-coded status per service (green/yellow/red)
2. What happened recently? — 30/90-day uptime percentage, incident timeline
3. Are we getting worse? — Response time trends, incident frequency

Key metrics to display:

• Current status (up / degraded / down)
• 30-day and 90-day uptime percentage (target: 99.9% = 43 minutes downtime per month)
• Mean time to recovery (MTTR)
• Average response time
• Incident count (last 7/30/90 days)

#How Vergate handles monitoring

Vergate combines uptime monitoring with threat detection in a single system. Every monitored target gets:

• Passive security re-scanning — detects new findings and regressions between scans
• Exposure checks — exposed .git, open ports, subdomain drift
• CVE intelligence — cross-references your tech stack against known vulnerabilities
• Alert on regression — email + Slack/Discord/Telegram when findings change

This means you're not just checking if the site is up — you're checking if it's still secure.

#Quick-start checklist

1. Pick a monitoring interval (60s for production, 5min for staging)
2. Set up at least 3 monitoring locations
3. Configure 2-3 consecutive failure threshold before alerting
4. Set response-time alerts (5s warning, 15s critical)
5. Add SSL certificate expiry monitoring (30 days warning)
6. Test your alerting by intentionally breaking a health check
7. Review and tune thresholds monthly

#Further reading

• Google Cloud Monitoring documentation — comprehensive guide to uptime checks and alerting
• PagerDuty Incident Response handbook — industry-standard incident management practices
• SRE Workbook by Google — practical reliability engineering
• RFC 7231: HTTP/1.1 Semantics — the spec behind HTTP status codes
• Uptime monitoring with Vergate — combined uptime + security monitoring