System status
What is running right now, answered by the running system rather than by this page.
Current readings, taken when you loaded this page
These figures come from /api/v1/health and /api/v1/uptime, fetched by your browser. If this page and those endpoints ever disagree, the endpoints are right.
The status of this system is a URL
A status page maintained by hand reports what someone remembered to update. These endpoints answer from the running system, and none needs a key or an account:
- /api/v1/health — service state and how many feeds are reporting. Point a monitor at this one.
- /api/v1/status — the current reading for every tracked port and chokepoint, with the true total.
- /api/v1/facts — every figure this site publishes, measured on the request, including the database's authorisation posture and the open integrity findings.
- /api/v1/uptime — the uptime record by day, with sample coverage alongside it.
- /openapi.json — the machine-readable description of the whole API.
These stay open permanently, so monitoring this service never requires buying it. The endpoints that return the record itself are licensed; see access. The Terminal and Atropos remain free in the browser.
Two numbers, because either one alone can flatter
- Uptime — the share of samples taken that were healthy.
- Coverage — the share of expected samples that were actually taken.
Both are published. A day with a single healthy sample is 100% uptime over 0.3% coverage, which is not a good day. The series is measured from inside the service, so a total outage records no sample rather than a failed one, which means a gap in coverage is the thing to read — and it is shown as a gap rather than smoothed over.
Sampling runs every five minutes. The record began in early September 2026 and lengthens daily.
Some sources are always degraded, and that is shown rather than hidden
Vaethra reads 55 public sources it does not control. At any moment a few are degraded: an agency is in maintenance, a rate limit has been reached, an account tier changed. The Terminal shows the live count in its header and the sources panel names the affected feed and quotes the error. The header and the board above both count feeds delivering — live or degraded — so a paused feed is not counted as reporting.
A source that stops delivering is recorded as a failure rather than as a quiet success, and a run that returns no records is not recorded as a clean run. This is why the header sometimes reads fewer than 55 reporting: it is the system describing its inputs accurately, not an outage of the service.
Sources are isolated from one another, so no single provider can affect availability. A provider outage affects the freshness of that source and nothing else.
What is committed, by tier
| Free (Terminal, Atropos) | Teams | Enterprise | |
|---|---|---|---|
| Availability commitment | None | None | 99.9% monthly, with service credits |
| Support response (Sev-1) | Best effort | 4 business hours | 1 hour, 24/7 |
| Maintenance notice | — | — | 5 business days |
The Terminal and Atropos are free and offered as they are. The enterprise
availability commitment is measured against the availability field
of the same public uptime endpoint above — not uptime. The
difference matters and is the reason the field exists: uptime is
the share of the samples we took that were healthy, and the sample is
written by the API itself, so an outage of the API writes no sample and the day
would still read 100%. availability divides by the samples
expected, so a missing sample counts against it exactly as a failed one
does. Exclusions are set out under
availability.
For a commitment in writing, tell us what you need.