Your website is the front door to your business. If it’s down and you don’t know, you’re losing revenue, trust, and potentially violating SLA commitments. Uptime monitoring solves this by continuously checking your site and alerting you when something goes wrong.
But not all monitoring is created equal. Here are the five main methods, ranked from simplest to most comprehensive.
1. HTTP/HTTPS Checks
The most common and most useful method. An external service sends an HTTP request to your URL and checks the response.
What it checks:
- Status code (expecting 200 OK)
- Response time (latency)
- SSL certificate validity
- Optionally, response body content
Best for: Websites, APIs, and any HTTP-accessible endpoint.
Limitation: Only tells you the endpoint responded. Doesn’t verify the page rendered correctly or that downstream services are healthy.
A basic HTTP check catches the majority of outages. If you can only set up one type of monitoring, this is it.
2. Keyword/Content Monitoring
An extension of HTTP checks that also verifies the response body contains (or doesn’t contain) specific strings.
What it checks:
- Everything HTTP checks cover, plus
- Presence of expected content (e.g., your brand name, a specific element)
- Absence of error strings (e.g., “500 Internal Server Error”, “Maintenance”)
Best for: Catching silent failures where the server returns 200 OK but serves wrong content, a cached error page, or a maintenance notice.
Example: A check that fetches your homepage and verifies it contains “Sign Up” would catch a deployment that accidentally broke the homepage, even though the server still returns HTTP 200.
3. TCP/Port Monitoring
Tests whether a specific network port is open and accepting connections, without sending HTTP-layer data.
What it checks:
- Port availability (is the service listening?)
- Connection time
Best for: Non-HTTP services: databases (PostgreSQL on 5432, MySQL on 3306), Redis (6379), SMTP (25/587), custom services.
Limitation: Confirms the port is open but doesn’t verify the service is functioning correctly. A database might accept connections but reject all queries.
4. DNS Monitoring
Verifies that your domain resolves correctly by querying DNS servers and comparing the response to expected records.
What it checks:
- Resolution success
- Correct IP addresses (A/AAAA records)
- Record changes that might indicate misconfiguration or hijacking
- Resolution time
Best for: Catching DNS propagation issues, nameserver outages, and domain hijacking attempts. DNS problems can make your entire service unreachable even when all servers are healthy.
DNS monitoring should be part of every monitoring setup. A DNS failure is invisible to HTTP checks if the monitoring agent has cached the DNS resolution.
5. Multi-Step (Synthetic Transaction) Monitoring
Simulates real user workflows by executing a sequence of requests, like logging in, navigating to a page, and performing an action.
What it checks:
- Full user flow functionality
- Authentication systems
- Checkout/payment flows
- API sequences with dependencies between calls
Best for: Critical business flows where individual endpoint checks aren’t enough. If your login page loads but authentication is broken, a simple HTTP check won’t catch it.
Limitation: More complex to set up, slower to execute, and harder to debug when they fail. Use them for your most critical 2-3 user flows, not for every page.
Which Method Should You Use?
For most teams, the answer is layered monitoring:
- HTTP checks on all important endpoints — your homepage, API health endpoint, key pages
- Keyword checks on critical pages — verify content is correct, not just served
- DNS monitoring — catch infrastructure-level issues
- TCP checks on non-HTTP services — databases, caches, queues
- Multi-step checks on business-critical flows — login, checkout, signup
Start with HTTP checks at 1-minute intervals from multiple regions. That alone will catch 90%+ of outages. Then layer additional methods based on what your SLA requires.
Setting Up Monitoring: Quick Start
- Pick your tool — Self-hosted (Warden, Uptime Kuma) or managed (Pingdom, Better Uptime, Datadog)
- Add your primary endpoint — Start with your homepage or API health check
- Set the check interval — 1 minute for most services, 10-30 seconds for critical ones
- Configure alerts — Slack for awareness, PagerDuty for on-call escalation
- Add more checks — SSL monitoring, DNS, key API endpoints
- Set up a status page — Communicate availability to your users
The best monitoring setup is one that’s actually running. Don’t overthink it. Get basic HTTP checks in place today, then iterate.
Related tools:
- Uptime Calculator — Calculate allowed downtime for any SLA
- Downtime Cost Calculator — Estimate the financial impact of outages
- Error Budget Calculator — Track your reliability budget