Uptime monitoring that alerts when most regions agree

The short answer#

• HTTP(S) and TCP checks run from Europe, the US and Asia-Pacific.

• An incident opens only when more than half of the regions see a failure; a region that cannot judge counts as unknown, never as down.

• Pass conditions cover status, body text, JSON values, headers, response time and TLS validity, with certificate expiry warnings.

• Probe addresses are published so you can allow them in your firewall.

• Up to 50 checks, every 60 seconds at most, during the beta.

What it catches#

A server that stopped, DNS that points nowhere, a firewall or CDN that blocks everyone, an expired certificate, a page that answers 200 with the wrong content. These are failures your error tracker cannot see, because your code never runs.

How a check is decided#

Each region checks once per interval. A round is:

An incident opens after 2 Down rounds in a row by default and closes after Up rounds in a row. Availability over 30 days is truncated, never rounded up, so a failed round in a month never shows 100 % (how Belvador decides).

Pass conditions#

By default a 2xx answer passes. Add body text, JSON values, headers, a response-time limit or a valid TLS certificate (pass conditions). TCP checks open a connection to host:port — useful for a database port or an SMTP relay.

A certificate that expires within 14 days shows a flag and sends at most one warning a day.

Where the probes run#

Allow these addresses if your firewall filters by source. Probes refuse private networks, localhost, cloud metadata addresses and Belvador's own hosts, both when you save and on every request (what probes refuse).

Alerts and evidence#

The default rule Uptime problems sends one message when a check goes down and one when it is back, through your own destinations (alerts). When a region fails, the probe can seal the status line, safe headers and the start of the body to your node's key; Belvador forwards it without being able to read it, and you open it on the check page.

Limits#

• Up to 50 checks, every 60 seconds at most, during the beta.

• HTTP(S) GET/HEAD and TCP only. No browser-based multi-step checks, no ICMP ping, no DNS-record checks.

• No public status page yet.

• Uptime results and timings are kept by Belvador's monitor service, not on your node — that is how it can alert while your node is down. Response bodies are never kept.

Questions#

Can an uptime check feed an SLO?#

Yes. Availability or latency from an uptime check can be an SLO with burn-rate alerts (SLOs). The error budget calculator shows what a target allows.

How do I tell probe traffic apart in my logs?#

Probes send a fixed User-Agent and come from the addresses above (how to recognise a probe).