Monitors

A monitor is a recurring check against an important target: a URL, a port, a TLS certificate. latency runs each check on a schedule with multi-region confirmation, keeps the history, and passes every result to the alert rules.

Beta

Monitors require an account. Sign-up and billing open during launch; the check types and rules below are the ones the engine runs today.

Monitor types

Each type maps to a built-in check run by the monitoring engine.

HTTP / HTTPS

Checks that an endpoint responds, how fast, and with which status code. The standard health check for websites and APIs.

• Records response time, status code and connection timing.
• Responses count as healthy when the status is below 400.

TCP

Checks that a raw TCP port accepts connections. The right check for databases, message queues and other non-HTTP services.

db.example.com:5432

TLS certificate

Connects over TLS and reads the certificate, so warnings arrive before expiry rather than after.

• Surfaces the certificate's expiry date.
• Pairs with certificate-expiry alerts to alert N days out.

Status page

Watches a service's own status page, so provider outages surface without any probing. Pick a service from the Status Catalog (Stripe, GitHub, or a custom entry) and watch the whole page, or only the components in use. The monitor is failing while the page reports a major incident or outage, degraded during a minor incident or degradation, and OK again once the page reports none. A setting decides whether any problem counts or only a major incident or outage. Alerts use the provider's own words: "Anthropic status: Incident (monitoring)" rather than a bare "failing". How the catalog reads pages, plus per-service policy for providers that file everything as major, is in the catalog.

• Status page monitors read the latest status taken from the page, checked once a minute, so Fail after and Recover after are minutes.
• A status that can't be read yet holds the monitor's current state.
• Not in the catalog? Add the status page there first, then watch the service.
• Status page monitors are check monitors: each counts toward the monitor limit, alerts like the others, and can join a composite, for example to page only when Stripe reports a problem and the checkout check fails too.

Detection rules

Monitors don't page on a single blip. Rules decide when a run, or a streak of runs, becomes an incident. The engine supports:

Rule	Fires when
Consecutive failures	N checks in a row fail (and recovers after M succeed).
Latency	Response time crosses a set threshold.
Certificate expiry	A TLS certificate is within N days of expiring.

Rules live in reusable sets shared across monitors, so one policy configured once applies everywhere.

Each rule marks matching runs fail, degraded or ok (an ok rule accepts an expected failure, such as a port that must stay closed). From those runs a monitor is OK, DEGRADED or FAILING: failing opens an incident, degraded is the warning beforehand, and monitors with no reading yet are UNKNOWN.

Check intervals

Every paid plan checks as often as every 15 seconds. The free plan checks every minute.

Plan	Fastest interval
Free	60 s
Hobby, Pro, Team, Founders	15 s

Full comparison on pricing.

Multi-region confirmation

Multi-region confirmation keeps a single flaky vantage point from paging anyone at 3 a.m.

What happens on a failure

1. A check fails.
2. A rule decides whether the failure crosses the line into an incident.
3. If so, an incident opens and alerts fire.
4. When checks recover, the incident closes automatically.

Related

• Alerts: where monitors send incidents
• Status Catalog: monitoring a provider's own status page
• Heartbeat Monitors: alerts when a cron job, backup or worker stops checking in

From what broke to why

Monitors show that something broke. Application logs, traces and metrics show why. Telemetry keeps both in the same console.