Uptime Monitoring: Tools, Best Practices, and Setup Guide

Downtime is expensive: lost revenue, support spikes, and damaged trust add up fast. Whether you're running an e-commerce store, SaaS application, or corporate website, uptime monitoring is essential for maintaining reliability and catching issues before users do.

This comprehensive guide covers everything you need to know about uptime monitoring, from basic concepts to advanced implementation strategies.

What is Uptime Monitoring?#

Uptime monitoring is the practice of continuously checking whether your website or application is accessible and functioning correctly. Monitoring tools send automated requests to your servers at regular intervals and alert you immediately when issues are detected.

Key Metrics#

Uptime Percentage:

Uptime % = (Total Time - Downtime) / Total Time × 100

Example:
Monthly uptime: 99.9%
Downtime allowed: 43.2 minutes per month

Uptime % = (Total Time - Downtime) / Total Time × 100

Example:
Monthly uptime: 99.9%
Downtime allowed: 43.2 minutes per month

Common service-level agreement (SLA) targets:

• 99.9% ("three nines"): 43.2 minutes downtime/month
• 99.95%: 21.6 minutes downtime/month
• 99.99% ("four nines"): 4.32 minutes downtime/month
• 99.999% ("five nines"): 26 seconds downtime/month

Response Time: How quickly your server responds to requests.

Good: <200ms
Acceptable: 200-500ms
Slow: 500-1000ms
Critical: >1000ms

Good: <200ms
Acceptable: 200-500ms
Slow: 500-1000ms
Critical: >1000ms

Why Uptime Monitoring Matters#

1. Revenue Protection

E-commerce site revenue: $100,000/day
Downtime: 1 hour
Lost revenue: $4,166

E-commerce site revenue: $100,000/day
Downtime: 1 hour
Lost revenue: $4,166

2. Customer Trust

• 88% of users won't return after a bad experience
• 1 hour of downtime = 1 week of lost trust

3. Search engine optimization (SEO) impact

• Google penalizes sites with frequent downtime
• Slow response times hurt search rankings

4. SLA compliance

• Meet contractual obligations
• Avoid penalties
• Maintain customer relationships

How Uptime Monitoring Works#

Basic HTTP monitoring#

// Monitoring tool sends request
GET https://example.com
Headers: { "User-Agent": "UptimeMonitor/1.0" }

// Expected response
Status: 200 OK
Response Time: 287ms
Body: Contains "Welcome"

// Result: ✅ Site is up

// Monitoring tool sends request
GET https://example.com
Headers: { "User-Agent": "UptimeMonitor/1.0" }

// Expected response
Status: 200 OK
Response Time: 287ms
Body: Contains "Welcome"

// Result: ✅ Site is up

Advanced Monitoring#

Multi-Step Checks:

// 1. Check homepage
GET https://example.com
Expect: 200 OK

// 2. Check login page
GET https://example.com/login
Expect: 200 OK

// 3. Check API
GET https://api.example.com/health
Expect: 200 OK, JSON (JavaScript Object Notation) response

// All steps pass: ✅ Site is fully operational

// 1. Check homepage
GET https://example.com
Expect: 200 OK

// 2. Check login page
GET https://example.com/login
Expect: 200 OK

// 3. Check API
GET https://api.example.com/health
Expect: 200 OK, JSON (JavaScript Object Notation) response

// All steps pass: ✅ Site is fully operational

Geographic Monitoring:

Check from:
- New York, USA (50ms)
- London, UK (120ms)
- Tokyo, Japan (180ms)
- Sydney, Australia (220ms)

Average: 142ms ✅

Check from:
- New York, USA (50ms)
- London, UK (120ms)
- Tokyo, Japan (180ms)
- Sydney, Australia (220ms)

Average: 142ms ✅

Types of Uptime Monitoring#

1. HTTP/HTTPS monitoring#

Basic availability checks.

{
  "url": "https://example.com",
  "method": "GET",
  "expected_status": 200,
  "interval": "1m",
  "timeout": "10s"
}

{
  "url": "https://example.com",
  "method": "GET",
  "expected_status": 200,
  "interval": "1m",
  "timeout": "10s"
}

Use case: Ensure website is accessible.

2. Ping Monitoring#

Network-level checks.

ping example.com
PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=56 time=12.3 ms

ping example.com
PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=56 time=12.3 ms

Use case: Check if server is online.

3. Port Monitoring#

Check specific services.

{
  "host": "example.com",
  "ports": [
    { "port": 80, "protocol": "HTTP" },
    { "port": 443, "protocol": "HTTPS" },
    { "port": 22, "protocol": "SSH" },
    { "port": 3306, "protocol": "MySQL" }
  ]
}

{
  "host": "example.com",
  "ports": [
    { "port": 80, "protocol": "HTTP" },
    { "port": 443, "protocol": "HTTPS" },
    { "port": 22, "protocol": "SSH" },
    { "port": 3306, "protocol": "MySQL" }
  ]
}

Use case: Monitor database, SSH, or custom services.

4. SSL Certificate Monitoring#

Track certificate expiration.

{
  "domain": "example.com",
  "check": "ssl_expiry",
  "alert_before": "30 days"
}

// Alert: SSL certificate expires in 25 days

{
  "domain": "example.com",
  "check": "ssl_expiry",
  "alert_before": "30 days"
}

// Alert: SSL certificate expires in 25 days

Use case: Prevent certificate expiration outages.

5. DNS Monitoring#

Verify DNS resolution.

dig example.com

;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34

dig example.com

;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34

Use case: Catch DNS propagation issues.

6. Keyword Monitoring#

Verify page content.

{
  "url": "https://example.com",
  "keyword": "Welcome to Example",
  "alert_if": "missing"
}

{
  "url": "https://example.com",
  "keyword": "Welcome to Example",
  "alert_if": "missing"
}

Use case: Detect defacement or content errors.

7. Transaction Monitoring#

Test complex user flows.

test("checkout flow", async ({ page }) => {
  await page.goto("/products");
  await page.getByTestId("add-to-cart").click();
  await page.getByTestId("checkout").click();
  await page.getByTestId("email").fill(process.env.TEST_EMAIL ?? "");
  await page.getByTestId("place-order").click();
  await expect(page.getByTestId("success")).toBeVisible();
});

test("checkout flow", async ({ page }) => {
  await page.goto("/products");
  await page.getByTestId("add-to-cart").click();
  await page.getByTestId("checkout").click();
  await page.getByTestId("email").fill(process.env.TEST_EMAIL ?? "");
  await page.getByTestId("place-order").click();
  await expect(page.getByTestId("success")).toBeVisible();
});

Use case: Monitor critical business processes.

Best Uptime Monitoring Tools#

1. ObserveOne#

Best for: Unified uptime monitoring + AI-generated Playwright suites

Features:

• HTTP/HTTPS monitoring
• Autopilot: AI-generated, self-healing Playwright suites from a URL
• API monitoring
• Multi-location checks
• Real-time alerts (Slack, Discord, email)
• Status pages

Pricing: Free tier, paid from $24/month

Example (conceptual config):

{
  "name": "Homepage Uptime",
  "url": "https://example.com",
  "interval": "1m",
  "locations": ["us-east-1", "eu-west-1", "ap-south-1"],
  "alerts": ["slack", "email"]
}

{
  "name": "Homepage Uptime",
  "url": "https://example.com",
  "interval": "1m",
  "locations": ["us-east-1", "eu-west-1", "ap-south-1"],
  "alerts": ["slack", "email"]
}

2. UptimeRobot#

Best for: Budget-friendly monitoring

Features:

• 50 monitors on free plan
• 5-minute intervals
• HTTP, ping, port monitoring
• Public status pages
• Email/SMS alerts

Pricing: Free for 50 monitors, $7/month for more

Best for: Startups and small projects.

3. Pingdom#

Best for: Enterprise uptime monitoring

Features:

• Global monitoring locations
• Real User Monitoring (RUM)
• Transaction monitoring
• Root cause analysis
• Mobile app

Pricing: From $10/month

Best for: Established businesses.

4. StatusCake#

Best for: Global coverage

Features:

• 30+ monitoring locations
• Page speed monitoring
• SSL monitoring
• Virus scanning
• Public status pages

Pricing: Free tier, paid from $24.49/month

Best for: International businesses.

5. Better Uptime (BetterStack)#

Best for: Developer-friendly monitoring

Features:

• Beautiful status pages
• Incident management
• On-call scheduling
• Phone call alerts
• API-first design

Pricing: From $18/month

Best for: Developer teams.

6. Datadog#

Best for: Full-stack observability

Features:

• Synthetic monitoring
• Application Performance Monitoring (APM) integration
• Infrastructure monitoring
• Log management
• Advanced analytics

Pricing: From $15/test/month

Best for: Large enterprises.

7. New Relic#

Best for: Application performance monitoring

Features:

• Synthetic monitoring
• Real user monitoring
• Distributed tracing
• Custom dashboards
• Alerting

Pricing: Free tier, paid from $99/month

Best for: Teams needing full observability.

8. Checkly#

Best for: API + browser monitoring

Features:

• Playwright-based checks
• API monitoring
• Monitoring as code
• Multi-location
• AI-assisted debugging for Playwright checks
• CI/CD (continuous integration/continuous deployment) integration

Pricing: Free tier, paid from $7/month

Best for: Developers who prefer code.

Comparison Table#

How to Set Up Uptime Monitoring#

Step 1: Identify Critical Endpoints#

List what needs monitoring:

Website:

• Homepage
• Login page
• Checkout page
• API endpoints

Infrastructure:

• Web servers
• Database servers
• Load balancers
• Content delivery network (CDN)

Step 2: Choose Monitoring Locations#

Select regions where your users are:

• us-east-1 (about 40% of users)
• eu-west-1 (about 35% of users)
• ap-southeast-1 (about 25% of users)

Step 3: Set Check Intervals#

Balance cost and detection speed:

• Critical endpoints (homepage, checkout): every 1 minute
• Important endpoints (blog, about): every 5 minutes
• Non-critical (archives, low-traffic pages): every 15 minutes

Step 4: Configure Alerts#

Set up notification channels, for example:

• PagerDuty: critical, when the site is down
• Slack: warning, when response time is > 1s
• Email: info, when SSL certificate expires in < 30 days

Step 5: Create Status Pages#

Share uptime with customers:

Public Status Page:
https://status.example.com

Shows:
- Current status (All systems operational)
- Uptime % (99.98% this month)
- Response time (287ms average)
- Incident history

Public Status Page:
https://status.example.com

Shows:
- Current status (All systems operational)
- Uptime % (99.98% this month)
- Response time (287ms average)
- Incident history

Step 6: Set Up Escalation#

Define who gets alerted when:

Level 1 (0-5 min): On-call engineer (Slack)
Level 2 (5-15 min): Team lead (Phone call)
Level 3 (15+ min): CTO (Phone call)

Level 1 (0-5 min): On-call engineer (Slack)
Level 2 (5-15 min): Team lead (Phone call)
Level 3 (15+ min): CTO (Phone call)

Best Practices#

1. Monitor from Multiple Locations#

Don't rely on single location:

// Bad: Single location
{ "location": "us-east" }

// Good: Multiple locations
{ "locations": ["us-east", "eu-west", "ap-south"] }

// Bad: Single location
{ "location": "us-east" }

// Good: Multiple locations
{ "locations": ["us-east", "eu-west", "ap-south"] }

2. Set Realistic Check Intervals#

Critical services: 1-5 minutes
Important services: 5-15 minutes
Non-critical: 15-60 minutes

Critical services: 1-5 minutes
Important services: 5-15 minutes
Non-critical: 15-60 minutes

3. Use Keyword Monitoring#

Verify content, not just status codes:

{
  "url": "https://example.com",
  "expected_status": 200,
  "expected_keyword": "Welcome", // Catches defacement
  "unexpected_keyword": "Error"  // Catches errors
}

{
  "url": "https://example.com",
  "expected_status": 200,
  "expected_keyword": "Welcome", // Catches defacement
  "unexpected_keyword": "Error"  // Catches errors
}

4. Monitor SSL Certificates#

{
  "ssl_check": true,
  "alert_before_expiry": "30 days"
}

{
  "ssl_check": true,
  "alert_before_expiry": "30 days"
}

5. Implement Retry Logic#

Avoid false positives:

{
  "retries": 2,
  "retry_interval": "30s",
  "alert_after": 2 // Alert after 2 consecutive failures
}

{
  "retries": 2,
  "retry_interval": "30s",
  "alert_after": 2 // Alert after 2 consecutive failures
}

6. Track Response Time Trends#

Week 1: 200ms average
Week 2: 250ms average ⚠️ Trend alert
Week 3: 350ms average 🚨 Investigation needed

Week 1: 200ms average
Week 2: 250ms average ⚠️ Trend alert
Week 3: 350ms average 🚨 Investigation needed

7. Test Your Alerts#

# Simulate downtime
sudo systemctl stop nginx

# Verify:
# Alert received within 1 minute
# Correct team members notified
# Status page updated

# Restore
sudo systemctl start nginx

# Simulate downtime
sudo systemctl stop nginx

# Verify:
# Alert received within 1 minute
# Correct team members notified
# Status page updated

# Restore
sudo systemctl start nginx

8. Document Runbooks#

Create response procedures:

# Downtime Response Runbook

## Step 1: Verify the Issue

- Check monitoring dashboard
- Verify from multiple locations
- Check server logs

## Step 2: Identify Root Cause

- Server down?
- Database issue?
- Network problem?
- DDoS attack?

## Step 3: Escalate if Needed

- Can't resolve in 5 min → Escalate to lead
- Can't resolve in 15 min → Escalate to CTO

## Step 4: Communicate

- Update status page
- Notify affected customers
- Post on social media if major outage

# Downtime Response Runbook

## Step 1: Verify the Issue

- Check monitoring dashboard
- Verify from multiple locations
- Check server logs

## Step 2: Identify Root Cause

- Server down?
- Database issue?
- Network problem?
- DDoS attack?

## Step 3: Escalate if Needed

- Can't resolve in 5 min → Escalate to lead
- Can't resolve in 15 min → Escalate to CTO

## Step 4: Communicate

- Update status page
- Notify affected customers
- Post on social media if major outage

Common Issues and Solutions#

Issue 1: False Positives#

Problem: Alerts for temporary network blips.

Solution:

{
  "retries": 2,
  "alert_after_failures": 2
}

{
  "retries": 2,
  "alert_after_failures": 2
}

Issue 2: Alert Fatigue#

Problem: Too many alerts, team ignores them.

Solution: Adjust thresholds:

// Before: Alert on every slow response
{ "alert_if": "response_time > 500ms" }

// After: Alert on sustained slowness
{ "alert_if": "avg_response_time_5m > 1000ms" }

// Before: Alert on every slow response
{ "alert_if": "response_time > 500ms" }

// After: Alert on sustained slowness
{ "alert_if": "avg_response_time_5m > 1000ms" }

Issue 3: Missing Regional Issues#

Problem: Site down in Asia, but monitoring only from US.

Solution: Add global locations:

{
  "locations": ["us-east", "eu-west", "ap-south", "sa-east"]
}

{
  "locations": ["us-east", "eu-west", "ap-south", "sa-east"]
}

Issue 4: SSL Expiration Surprises#

Problem: Certificate expires unexpectedly.

Solution: Monitor SSL:

{
  "ssl_monitoring": true,
  "alert_at": ["60d", "30d", "7d", "1d"]
}

{
  "ssl_monitoring": true,
  "alert_at": ["60d", "30d", "7d", "1d"]
}

Uptime Monitoring Checklist#

Setup:

• Monitor critical endpoints
• Check from multiple locations
• Set appropriate intervals
• Configure SSL monitoring
• Set up DNS monitoring

Alerts:

• Configure notification channels
• Set up escalation policy
• Test alert delivery
• Document runbooks

Status Pages:

• Create public status page
• Add uptime history
• Enable incident updates
• Share URL (web address) with customers

Maintenance:

• Review alerts weekly
• Update thresholds monthly
• Test failover quarterly
• Audit monitoring annually

Conclusion#

Uptime monitoring helps you detect issues before customers do and meet SLA commitments. Monitor from multiple locations, set realistic check intervals, and use retry logic to avoid false positives.

Sign up for ObserveOne's free tier to set up uptime monitoring and AI-generated Playwright suites with Autopilot in minutes.