Availability
Uptime as measured, the monitoring behind it, maintenance windows, and the enterprise service level.
Published on an endpoint anyone can read
Availability is sampled continuously and published at api.vaethra.com/api/v1/uptime, which needs no key and no account. It reports availability per day, the sample coverage behind each figure, and how many data feeds were reporting.
Sample coverage is published beside the percentage because a figure drawn from four samples is a different claim from one drawn from a thousand, and a status page that shows only the percentage does not let you tell them apart.
Continuous sampling began recently, so the published window is currently short and lengthens daily. If your procurement process requires twelve months of history, we do not have it yet.
What has to fail before service is affected
- The edge is stateless and globally distributed. The API, Terminal and Atropos run in Cloudflare's network at hundreds of locations. There is no primary region to lose, and a failed location is routed around by the platform without action from us.
- A read never waits on a data provider. Provider calls run on a schedule, off the request path. An upstream outage affects freshness and is shown on the sources panel; it does not affect availability.
- One data source cannot take the system down. Each of the 55 sources runs in isolation with its own time budget and records its own health.
- Responses are cached at the edge by class, so a traffic spike is absorbed by the CDN rather than by the database. The most expensive responses are additionally pre-built on a schedule.
- The database is the one component without a hot standby in the current design. It is managed, backed up and monitored, and recovery is covered under business continuity. While it is unreachable, cached responses continue to serve.
- Authorisation fails closed, and so does caching. A refused request never reads from or writes to the shared cache, so a credential problem cannot become a data exposure.
Four layers
| Layer | Watches | Public |
|---|---|---|
| Service health | /api/v1/health and /api/v1/status,
answered by the running system | Yes |
| Source health | Every source's last run: records retrieved, records written, latency, failure reason | Yes, on the sources panel |
| Scheduled-job health | Every job's last run against its schedule | No — job names and error text are operational |
| Data integrity checks | Whether work that completed successfully accomplished anything | Summarised on status |
The fourth layer is the one worth explaining. Conventional monitoring answers whether a job ran. These checks answer whether it did what it was for: a cursor incrementing its counters without advancing, a source rewriting unchanged records, a filter matching nothing because the column it reads is empty, a licence filter that has stopped filtering.
Alerts are sent when a problem appears and again when it clears, with a daily summary of anything still open. They fire on state change rather than on a fixed interval, so that a channel people watch stays worth watching.
Routine deployments cause no downtime
- Deployments are zero-downtime. A new version is uploaded and traffic moves to it; there is no restart and no connection drain.
- Deployments happen during working hours, so that anyone who needs to respond to one is available.
- Schema changes are additive first. A column is added, written, backfilled and only then read from, so the old and new application versions can run at the same time.
- Where impact is expected, enterprise customers receive 5 business days' notice by email with the window, the expected effect and the rollback plan, and never inside a customer's stated business hours without agreement.
- Emergency maintenance — a security fix that cannot wait — is announced as it begins and is followed by the same written report an incident receives.
What is committed, by tier
| Free (Terminal, Atropos) | Licensed API | Enterprise | |
|---|---|---|---|
| Availability commitment | None | None | 99.9% monthly, with service credits |
| Measured against | The same public uptime endpoint anyone can read | ||
| Support response (Sev-1) | Best effort | 4 business hours | 1 hour, 24/7 |
| Status | Public, including failures | ||
The Terminal and Atropos are free and offered as they are, without an availability commitment.
The enterprise commitment is 99.9% monthly availability of the API, measured against the same public uptime endpoint you can read yourself, with service credits against the following month's fee. The following are excluded from the calculation:
- Scheduled maintenance announced 5 business days in advance.
- Upstream data provider outages. A provider outage is a degraded source, visible on the sources panel, and is not unavailability of Vaethra. This distinction is written into the agreement rather than left to interpretation.
- Force majeure, and faults in the customer's own network.
The credit schedule is set out in the enterprise agreement. Ask and we will send the clause.