Uptime monitors

An Uptime monitor has Drumbeats poll a public HTTP endpoint from outside on a schedule. Your service does not call Drumbeats — Drumbeats calls your service.

Use an Uptime monitor for APIs, marketing sites, health endpoints, or any URL that should respond 2xx from the public internet. For internal jobs or queue workers, use one of the Cron / Heartbeat / Event-driven monitor types instead.

What gets checked

Each scheduled check sends one HTTP request to your URL and records four things:

• HTTP status code — 200, 404, 502, etc.
• Response time — round-trip in milliseconds.
• Up / down determination — status code matches the expected list, and the response arrived inside the timeout.
• Error reason — timeout, dns_failure, connection_refused, ssl_error when the check failed.

Configuration

Create an Uptime monitor

From the dashboard, click New monitor → Uptime, paste the URL and pick an interval. Monitoring starts immediately.

From the REST API:

curl -X POST https://api.drumbeats.io/v1/monitors \
  -H "X-API-Key: $DRUMBEATS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": "<project-id>",
    "name": "Production API health",
    "type": "UPTIME_HTTP",
    "schedule": "5m",
    "uptime_url": "https://api.myapp.com/health",
    "uptime_method": "GET",
    "uptime_timeout_ms": 5000,
    "failure_tolerance": 3
  }'

curl -X POST https://api.drumbeats.io/v1/monitors \
  -H "X-API-Key: $DRUMBEATS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": "<project-id>",
    "name": "Production API health",
    "type": "UPTIME_HTTP",
    "schedule": "5m",
    "uptime_url": "https://api.myapp.com/health",
    "uptime_method": "GET",
    "uptime_timeout_ms": 5000,
    "failure_tolerance": 3
  }'

False-positive suppression

A single failed check does not trigger an alert. When the check fails, Drumbeats retries twice with a 5-second pause between attempts. Only after all three checks fail in a row does the monitor flip to DOWN and open an incident.

This keeps short network blips off your channel. Tune failure_tolerance higher if your endpoint is more flaky than your team's tolerance for false positives.

Recovery

When the next check (after the failure tolerance has been exceeded) returns a passing status, Drumbeats:

1. Closes the incident with a RESOLVED status.
2. Flips the monitor to UP.
3. Sends a recovery notification to the assigned notification group.

Beats consumption

Each uptime check costs 1 beat per check location, same as any ping. A monitor checked from one location (the default, Europe) costs 1 beat per cycle; a monitor checked from 2 locations (Europe plus, in beta, US East) costs 2 beats per cycle instead of 1. A 5-minute interval on a single-location monitor = 288 checks/day = ~8 700 checks/month per URL — double that for a 2-location monitor. Mix Uptime checks with Cron / Heartbeat / Event-driven pings — they share the same beats pool. See Beats and usage for the math.

Check locations (beta)

By default, Uptime monitors check from a single location in Europe (eu-central). In beta, you can add a second location, US East (us-east) — Drumbeats only opens an incident if all checked locations agree the endpoint is down, which filters out false positives caused by a bad route from a single vantage point. A probe that's unreachable counts as unknown for that location, never as a failure. See the firewall table below for each location's egress IP.

Reach Drumbeats through your firewall

Uptime checks originate from a small set of static IPs. Allowlist them on your WAF / firewall to avoid filtering check requests.

If your monitor opts into the beta us-east check location (see Check locations (beta) above), checks from that location will originate from a different IP than the Europe row above. Until the US East IP is published, allowlist only the Europe IP if your firewall requires an exact list, and keep us-east off that monitor for now.

Each request also carries this User-Agent header — useful if your filters are user-agent-based:

Drumbeats/1.0 (+https://drumbeats.io/docs/monitor-types/uptime)

Drumbeats/1.0 (+https://drumbeats.io/docs/monitor-types/uptime)

Reading check history

The REST API exposes both the live state and the historical record:

# Latest check result
GET /v1/monitors/<id>/check-results/latest

# Paginated history (default 50 per page)
GET /v1/monitors/<id>/check-results?page=1&limit=50

# Response-time stats over a window
GET /v1/monitors/<id>/response-time-stats?period_hours=24

# Latest check result
GET /v1/monitors/<id>/check-results/latest

# Paginated history (default 50 per page)
GET /v1/monitors/<id>/check-results?page=1&limit=50

# Response-time stats over a window
GET /v1/monitors/<id>/response-time-stats?period_hours=24

The same data drives the monitor's status page when public sharing is enabled.

Status pages

Uptime monitors are eligible for public status pages. The status page shows current state, 24h / 7d / 30d uptime percentages, recent incidents, and response-time charts. See Status pages to publish one.

Related guides

• Monitor types overview — when Uptime is the wrong choice.
• Notifications: channels — route uptime incidents to the right team.
• Status pages — share uptime data publicly.
• REST API: monitors — programmatic CRUD over uptime monitors.