How to Set Up HTTP Uptime Monitoring

What is an HTTP Check?

An HTTP check sends a real HTTP request from Xitoring's global probing nodes to your URL and validates the response. Unlike Ping, an HTTP check verifies that the web server is actually serving traffic — not just that the host is reachable.

Use HTTP checks for:

Public websites and landing pages served over plain HTTP
Internal admin tools on private networks (with a private probing node)
Health endpoints exposed by APIs and microservices
Legacy services that haven't migrated to HTTPS

For TLS-protected endpoints, use the HTTPS check instead.

What Gets Monitored

HTTP status code — 2xx, 3xx, 4xx, 5xx
Response time — total request duration per node
Response body content — keyword presence/absence
Custom headers in the response
Redirect chains — followed or treated as a failure
Geographic latency — performance from each probing node

Prerequisites

A reachable HTTP URL (e.g., http://example.com/health)
The endpoint allows requests from Xitoring's probing IP ranges (no IP allow-list blocking)
For authenticated endpoints, an API token or basic-auth credentials you can configure

How to Set Up an HTTP Check

Step 1: Create the Check

Log in to your Xitoring Dashboard
Go to Uptime → Add Check
Select HTTP as the check type

Step 2: Configure the Request

Enter the full URL (e.g., http://example.com/health)
Choose the HTTP method (GET, POST, PUT, HEAD, etc.)
Set the check interval (30 seconds to 15 minutes)
Set the timeout (default: 30 seconds)

Step 3: Configure Validation

Expected status code — default is 200. Set explicitly if your endpoint returns 204, 302, etc.
Keyword check — assert a substring exists (or doesn't exist) in the response body
Custom headers — add auth tokens, API keys, or custom User-Agent
Request body — for POST/PUT, send JSON or form data

Step 4: Choose Probing Nodes

Select at least 3 nodes across different regions to avoid false positives.

Step 5: Assign Notifications

Under Triggers, attach a notification role so the right people get paged when the check fails.

Step 6: Save and Verify

Save the check. The first probe runs immediately and the dashboard updates within seconds.

Setting Up Triggers

Common alerting rules:

Status code mismatch — response code differs from expected
Keyword missing — required text not found in body (e.g., "status":"ok")
Slow response — response time exceeds your SLA threshold
Down — repeated failures from N nodes confirm a real outage

Tips

Use a dedicated /health or /status endpoint rather than your homepage — it's lighter, deterministic, and won't pull in third-party scripts
Add a keyword check for "status":"ok" or similar — a 200 response with a generic error page would otherwise pass
Set expected status to 200 explicitly. Don't rely on "any 2xx is fine" if your endpoint always returns 200
Use HEAD instead of GET for static assets to reduce bandwidth
Migrate to HTTPS when possible — HTTP-only checks can't catch SSL/TLS issues