Monitors

A monitor is a recurring check against something you care about: a URL, a port, a TLS certificate. Latency runs it on a schedule from multiple regions, keeps the history, and hands the result to your 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 the monitoring engine runs for you.

HTTP / HTTPS

Checks that an endpoint responds, how fast, and with what status code. The standard health check for a website or API.

• Records response time, status code, and connection timing.
• A response is considered healthy when its status is below 400.

TCP

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

db.yourdomain.com:5432

TLS certificate

Connects over TLS and reads the certificate, so you can be warned before it expires rather than after.

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

Detection rules

A monitor doesn't page you 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 threshold you set.
Certificate expiry	A TLS certificate is within N days of expiring.

Rules are grouped into reusable sets and shared across monitors, so you configure a policy once and apply it everywhere.

Check intervals

How often a monitor runs depends on your plan. Faster intervals catch problems sooner.

Plan	Fastest interval
Hobby	60 s
Full	30 s
Enterprise	15 s

See pricing for the full comparison.

Multiple regions

Checks run from several regions at once. A failure seen from only one region is treated with suspicion. An incident escalates when the failure is corroborated, so a single flaky vantage point doesn't page you at 3 a.m.

What happens on a failure

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

Related

• Alerts: where a monitor sends its incidents
• Status catalog: monitor a provider's own status page