# Uptime: know when your site or service stops answering

> Create an HTTP or TCP check, run it from three regions and decide by majority; statuses, incidents, alerts, certificates and where data lives.

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.

| You want to know when… | Use |
|---|---|
| A page, API or port stops answering | An uptime check (this page) |
| A scheduled job or worker stops running | A [ping URL](https://belvador.dev/en/docs/monitors/heartbeat) or a [monitor](https://belvador.dev/en/docs/monitors/overview) |
| Your code throws | Error tracking ([quickstart](https://belvador.dev/en/docs/quickstart)) |

## 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](https://belvador.dev/en/docs/uptime/probes#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](https://belvador.dev/en/docs/uptime/assertions).
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:

| Region results in the round | Round |
|---|---|
| Every region with a result is up | **Up** |
| Some are down, but no more than half | **Degraded** — some regions cannot reach you; no incident |
| More than half of them are down | **Down** — with two regions, both |
| Fewer than 2 regions have a definite result | **Unknown** |

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

| Status | Meaning |
|---|---|
| **Up** | The last round passed in every region |
| **Degraded** | Some regions fail — often a regional network or CDN problem |
| **Down** | An incident is open |
| **Unknown** | Not enough regions could judge the last rounds |
| **Paused** | Not checking, until the time you chose or until you resume |
| **Waiting for first result** | Created or resumed; the first round has not been decided yet |

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](https://belvador.dev/en/docs/alerts) — Telegram, Slack, email or a [webhook](https://belvador.dev/en/docs/alerts/webhooks). 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](https://belvador.dev/en/docs/uptime/probes).