HTTP Monitoring

Monitor website and API availability with expected status rules.

HTTP monitors run synthetic requests to a URL and compare response status codes against your expected rule. Results update check status and response time, then flow through incidents + notifications.

Supported Methods

PulseBeacon currently supports GET, HEAD, and POST for HTTP monitors.

Configuration Fields

Field	Purpose
URL	Target endpoint to request.
Method	GET, HEAD, or POST.
Expected status	Rule parser supports ranges and lists (for example `200-299`, `200,301`).
Headers	Optional custom headers, one per line (`Key: Value`).
Follow redirects	Enable/disable redirect following.
Request body	Optional raw body for POST requests.
Timeout	Per-request timeout in seconds (bounded in runner).
Interval	Run frequency; minimum is plan-aware and at least 60s for synthetic checks.

Expected Status Modes

Any 2xx: stored as 200-299.
Any 2xx/3xx: stored as 200-399 (useful when redirects are an acceptable response).
Exact code: for example 200.
Custom range: for example 200-204.
Advanced raw rule: comma-separated values and ranges.

Headers Format

Authorization: Bearer YOUR_TOKEN
X-Environment: production
Accept: application/json

Practical Setups

Website Uptime

URL: https://example.com
Method: GET
Expected: 200-299
Interval: 60
Timeout: 10

API Health Endpoint

URL: https://api.example.com/health
Method: HEAD
Expected: 200
Interval: 60
Timeout: 5

POST Check with Body

URL: https://api.example.com/ping
Method: POST
Expected: 200-299
Body: {"check":"ping"}
Headers: Content-Type: application/json

Failure Confirmation & Alerts

A single failed probe (timeout, DNS problem, connection error, unexpected status) does not mark the monitor down — it enters Confirming… and is re-probed with short spacing.
The monitor is marked down only after consecutive confirmed failures (3 by default). Then exactly one check_down alert goes out per channel.
If a confirmation probe succeeds, the monitor stays up and the blip is logged as a transient failure — with no notification and no impact on uptime.
Confirmed recovery marks the check up and sends one check_up alert.
Status pages always show the confirmed state, so unconfirmed blips never appear as public outages.

See Reliability & Alerting for the full confirmation model.