Availability

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. Samples are retained for 400 days, which the endpoint publishes as retentionDays, so the series grows into a rolling twelve months and then holds there. If your procurement process requires twelve months of history today, we do not have it — ask for the date the window reaches your requirement and we will give you the arithmetic rather than an estimate.

This sentence used to say "we do not have it yet" against a 90-day retention, which meant twelve months was never going to arrive. The retention was raised rather than the sentence softened.

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

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.

Findings are recorded when a problem appears and again when it clears, with a daily summary of anything still open, and the open set is published on the status page. Alerts fire on state change rather than on a fixed interval, so that a channel people watch stays worth watching. Transitions and the daily digest are delivered to the operations mailbox; the security overview records when that became true.

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 run from the pipeline on every change to the default branch, at whatever hour the change lands. The engineering owner is the one who lands it and is therefore present for it, and the pipeline's post-deploy verification reports what shipped.
• 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

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 availability field of the 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 published in the Enterprise Service Addendum, which an enterprise order form incorporates.