Monitoring

Uptime Monitors

Automated HTTP checks that test your endpoints at configurable intervals. When failures exceed a threshold, Beacon creates an incident, notifies subscribers, and degrades linked components -- all without manual intervention.

What monitors do

A monitor performs an HTTP request to a URL you specify on a recurring schedule. Each check records whether the response matched the expected status code and, optionally, whether the response body contained (or did not contain) a specific keyword.

When consecutive failures exceed the configured threshold, Beacon automatically:

• Creates a new incident on the linked status page
• Sets the linked component status to major_outage
• Sends notifications to all page subscribers

When the monitor recovers, the incident is automatically resolved, subscriber notifications are sent, and the component status returns to operational.

Creating an HTTP monitor

Navigate to your status page, open the Monitors tab, and click Add Monitor. Fill in the following fields:

Monitor states

Every monitor is in one of three states at any given time:

How failure detection works

Beacon does not create an incident on the first failed check. Instead, it tracks consecutive failures against the configured threshold. This prevents false alarms caused by transient network issues, brief DNS hiccups, or momentary server restarts.

For example, with a threshold of 3 and a 1-minute interval:

• Check 1 fails -- consecutive failures: 1 (no incident)
• Check 2 fails -- consecutive failures: 2 (no incident)
• Check 3 fails -- consecutive failures: 3 (threshold reached, incident created)

If check 2 had succeeded, the counter would have reset to 0 and no incident would be created.

Auto-incident creation

When the failure threshold is exceeded, Beacon creates an incident with the following properties:

The auto-created incident appears on the public status page immediately and triggers subscriber notifications.

Auto-resolution

When a monitor in the down state receives a successful check, Beacon automatically:

• Resolves the active auto-incident with a "Monitor recovered" update message
• Resets the consecutive failure counter to 0
• Sets the monitor state back to up
• Restores the linked component status to operational
• Sends recovery notifications to subscribers

Linked components

Linking a monitor to a component creates a two-way relationship between monitoring and status communication:

• On failure — the component status changes to major_outage
• On recovery — the component status returns to operational

This means your public status page always reflects the real-time health of your monitored services without any manual updates.

Keyword matching

Beyond status code checks, you can verify response body content with keyword matching. This catches cases where a server returns 200 OK but the response body indicates an error.

Contains

The check passes only if the response body contains the specified string. Useful for verifying that a health endpoint returns the expected response.

# Your health endpoint returns:
{"status": "healthy", "database": "connected"}

# Keyword: "healthy"
# Match type: contains
# Result: PASS -- "healthy" is found in the response body

Not contains

The check passes only if the response body does NOT contain the specified string. Useful for detecting error messages in responses that still return 200.

# Your endpoint returns on error:
{"status": "error", "message": "database unreachable"}

# Keyword: "error"
# Match type: not_contains
# Result: FAIL -- "error" was found in the response body

Plan limits

Best practices

What to monitor

Monitor dedicated health endpoints, not full web pages. Health endpoints are lightweight, fast, and specifically designed to report service status. A typical health endpoint:

// GET /health
{
  "status": "healthy",
  "database": "connected",
  "cache": "connected",
  "queue": "running"
}

Choosing thresholds

• Threshold 3 — Good default for most production endpoints. Catches real outages quickly while filtering transient failures.
• Threshold 5+ — Use for endpoints with known intermittent issues or high network variability.
• Threshold 1 — Only use when immediate detection is critical and you accept the risk of false positives.

Link critical monitors to components

Always link monitors to their corresponding components. This ensures your public status page reflects real-time service health without requiring manual status updates during an outage.