Uptime: know when your site or service stops answering

An uptime check asks your site or service, from outside, whether it still answers. Belvador's probes in up to 3 regions send the request; Belvador compares their answers and opens an incident only when most regions agree something is wrong. It catches what error tracking cannot see: a server that stopped, DNS that points nowhere, an expired certificate, a CDN or firewall that blocks everyone. Nothing to install in your app.

1. Create a check#

Open Uptime → New check.

1. Kind — HTTP(S) sends a GET or HEAD request; TCP only opens a connection to host:port (for a database port, SMTP relay, game server…).

2. Target — a public URL or host:port. Private networks, localhost, cloud metadata addresses and Belvador's own hosts are refused when you save and again on every request; see what probes refuse. A URL with a user name or password inside it is refused; a query key that looks like a token (token, key, secret…) gets a warning, because the full URL is part of the check settings.

3. Regions — at least 2. The form shows where each region runs.

4. Interval — 60, 120, 300, 600, 1800, 3600 seconds. How many checks you can have and the shortest interval depend on your plan; the form shows your limits.

5. Pass conditions — by default a 2xx answer passes (also 3xx when redirects are not followed). Add body text, JSON values, headers, a response-time limit or a valid TLS certificate: see Pass conditions.

6. Save. The first round runs right away; the result appears within one interval.

Timeout is 10 s by default (1–30 s). Redirects are followed up to 3 hops unless you turn that off. You may add up to 10 request headers; authorization, cookie, host, content-length, transfer-encoding, connection, te, upgrade and any proxy-* or sec-* header cannot be set.

2. How Belvador decides#

Each region checks once per interval, at a fixed offset per check so that not every check hits at the same second. A round is decided 15 s after the interval ends plus the timeout:

An incident opens after N Down rounds in a row (default 2, up to 5) and closes after M rounds in a row that are Up or Degraded. Unknown rounds neither break nor extend a streak. So the time from the first failed request to the alert is between (N − 1) × interval + timeout + 15 s and N × interval + timeout + 15 s — the form shows this window for your settings.

Unknown never means Down. A region's result is unknown when Belvador could not judge your service fairly: the per-target rate cap made the request wait too long, the target resolved to a refused address, the probe itself failed, or a region's probe stopped reporting for more than 2 × the shortest interval (shown as unobserved). If fewer than 2 regions are observed, every check shows Unknown instead of guessing.

3. Statuses#

A TLS certificate expires in N days flag appears beside the status when an HTTPS certificate expires within the warning period (default 14 days, 1–60).

Availability over 30 days is the share of decided rounds that were Up or Degraded. Unknown and paused time is left out, not counted as up. The figure is truncated, never rounded up: 99.996 % shows as 99.99 %, and one failed round in a month never shows 100 %.

4. Check now, pause and mute#

• Check now runs the check once in every selected region and shows each region's answer and timings. It is limited to 6 runs per minute per check and never opens or closes an incident.

• Pause stops checking until a time you choose, or until you resume. Paused time does not count against availability.

• Mute alerts keeps checking and recording, but sends no alerts.

5. Alerts#

Every workspace starts with the default rule Uptime problems. It sends one message when an incident opens and one when it recovers, through your own destinations — Telegram, Slack, email or a webhook. A check that opens a new incident within the rule's Don't repeat for window does not alert again. A certificate that is about to expire sends at most one message per day.

Messages name the check, project, environment, target without its query string, the failure reason and the failing regions. They never contain response bodies, headers or your request headers.

6. Where uptime data lives#

Uptime is the one place where Belvador itself measures your service, so it is a published exception to "your data stays on your node":

• Kept by Belvador: each round's result, the failure reason, status code, phase timings (DNS, connect, TLS, first byte, download), certificate expiry and which regions failed — per minute for 3 days, per hour for 90 days.

• Never kept by Belvador: the response body. A probe reads at most 64 KB into memory to check your conditions, then drops it.

• Failure evidence (on by default, per check): when a region fails, the probe seals the status line, a fixed list of safe headers and the first 8 KB of the body (with secrets filtered) to your node's key. Belvador forwards the sealed box without being able to open it; only your node can. The node keeps the newest 100 per check, for as long as it keeps errors. Open it on the check page under Failure evidence. Turn it off per check with Evidence on failure.

• Metadata only (optional, per check): Belvador receives only pass/fail, a coarse reason group (network, HTTP, condition) and certificate expiry. Status codes and timings then travel only inside the sealed evidence, if evidence is on.

Who the probes are and how a site owner can stop them: Probes and IPs.