HTTP Response Monitoring: Detect Failures by Status Code

When a site goes down, the question is not whether you will find out — it is whether you find out before your client does. HTTP response monitoring is the foundational layer of uptime monitoring: it checks whether the server is returning the right response code on every request, and alerts you the moment it stops.

This guide covers how to configure HTTP response monitoring to catch real failures quickly, minimize false positives, and respond effectively — with concrete Miterl setup examples.

HTTP Status Codes and Failure Classification

Every HTTP response includes a three-digit status code indicating what the server did with the request.

When Miterl Marks a Monitor as DOWN

Miterl triggers a DOWN state — and sends an alert — when:

• The server returns a 5xx status code
• No response arrives within the configured timeout window
• The connection is refused (server not listening)
• DNS resolution fails

Status-Code Alert Policy

5xx Errors: Alert Immediately

Server errors indicate a problem on the server side and warrant an immediate alert.

For agencies managing WordPress client sites, a 500 after a plugin update or a bulk content generation process is the most common trigger. Set up alerts so you catch these before clients call.

4xx Errors: Context-Dependent

Client errors indicate a problem with the request itself, not necessarily a site-wide outage.

Note on authentication: Monitoring tools are not browsers. If the URL you are monitoring sits behind Basic Auth, the monitor will receive a 401 unless you pass credentials in the request headers. Miterl supports custom request headers to handle this.

Timeouts: Alert Immediately

A timeout means no status code came back at all. Common causes:

• Server is not running (hosting outage)
• Firewall blocking the monitoring probe's IP
• Network path issue between the probe and server
• Server queue full under extreme load

Set the timeout threshold at 5–10× the site's typical response time. A site that normally responds in under one second can safely use a 5-second timeout without false positives.

Miterl Setup: Step by Step

Creating a Basic HTTP Monitor

# Create an HTTP monitor — 5xx and timeouts trigger DOWN automatically
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/",
    "name": "example.com - Corporate Site",
    "type": "http",
    "interval_seconds": 60,
    "alert_contact_ids": [1, 2]
  }'

interval_seconds: 60 checks every minute. Use 60 seconds for business-critical sites, 180 seconds for lower-priority sites.

Monitoring a URL Behind Authentication

For admin panels or member areas, pass credentials in the request headers:

curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/admin/",
    "name": "example.com - Admin Panel",
    "type": "http",
    "interval_seconds": 180,
    "request_headers": {
      "Authorization": "Basic dXNlcjpwYXNzd29yZA=="
    },
    "alert_contact_ids": [1]
  }'

Checking Monitor Status via API

# Check the current status of a specific monitor
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '{name: .name, status: .status, uptime_30d: .uptime_30d}'
# Output: {"name": "example.com", "status": "up", "uptime_30d": 99.97}

Reducing False Positives

Retry Before Alerting

Most brief HTTP failures — a momentary network hiccup, a brief server spike — resolve within 30–60 seconds without human intervention. Alerting on the first failed check generates noise that desensitizes your team to real incidents.

Configure Miterl to confirm the failure across multiple consecutive checks before sending an alert:

• Corporate sites: Alert after 2 consecutive DOWN checks
• E-commerce / booking systems: Alert after 1 DOWN check (revenue impact is immediate)

Quiet Hours for Low-Priority Sites

Overnight alerts for sites that recover automatically within 2–3 minutes train your team to ignore alerts. For sites where clients do not expect 24/7 response, configure quiet hours to suppress off-hours notifications for minor incidents.

For a full guide to balancing sensitivity and noise, see "Preventing Alert Fatigue in Website Monitoring."

Detection-to-Recovery Flow

[Miterl detects 5xx or timeout]
        ↓
[Retry after 1 minute]
        ↓
[2 consecutive DOWN checks → alert fired (Slack + email)]
        ↓
[On-call engineer receives alert → investigates]
        ↓
[Root cause identified: server log for 5xx, hosting panel for timeout]
        ↓
[Fix applied (PHP error resolved, service restarted)]
        ↓
[Miterl detects 2xx → UP alert sent (recovery notification)]
        ↓
[Client notified with initial report + timeline]

The full incident response playbook from alert receipt through client communication is in "Website Incident Response Guide for Web Agencies."

Monitoring Multiple Sites at Scale

Agencies often manage dozens of client sites simultaneously. Use the Miterl API to get a real-time status dashboard:

# List all monitors with current status
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq -r '.data[] | "\(.status) | \(.name)"'
# Output:
# up | Client A - Corporate Site
# down | Client B - E-commerce Site   ← active incident
# up | Client C - Booking System

Filter to only DOWN monitors for a quick triage view:

# Show only DOWN monitors
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq -r '.data[] | select(.status == "down") | "\(.name): last checked \(.last_checked_at)"'

Common HTTP Failure Patterns and Causes

Summary

Effective HTTP response monitoring starts with a clear definition of what counts as a failure and how quickly you escalate.

• 5xx errors and timeouts are always immediate alert triggers
• 4xx errors require context — check whether the issue is in the monitor configuration or a real content problem
• Use retry settings and quiet hours to suppress false positives without hiding real failures
• Pull status across all client sites via the API to catch incidents before clients report them

HTTP response monitoring tells you whether the site is up or down. It does not tell you whether it is slow. For detecting response time degradation before it causes visible problems, see "Response Time Monitoring Guide: Detecting HTTP Response Failures Early." SSL certificate expiry also causes HTTP failures — HTTPS stops working when the certificate lapses. To catch expiry before it becomes an outage, see "How to Prevent SSL Certificate Expiry Incidents with Automated Monitoring."

Sign up for free to start monitoring your client sites. Full feature documentation is at /en/docs. Agency-specific workflows are covered in the use cases section. Common questions are answered in the FAQ.