Skip to content

Status

Checked while this page loaded

Four calls against the production API, made from this server as you requested the page. Nothing below is cached and nothing is a stored verdict — reload and they run again.

Every check answered.

slowest round trip 371 ms

the checks

Each one proves something the one above it does not

Timings are the round trip from our own server, which sits in the same region as the API. They are a service figure rather than what a browser in another country sees — for that, the latency rail on the home page measures your own connection.

  • Service

    The API process is answering.

    GET /health
    321 ms
  • Contract

    The application booted and is serving its own event vocabulary.

    GET /v1/meta/event-types
    297 ms
  • Configuration

    The published limits resolve — what a client validates against before it holds a key.

    GET /v1/meta/limits
    297 ms
  • Authenticated read

    The whole chain a customer depends on: key resolution, metering, the geohash index and the store behind it.

    GET /v1/events
    371 ms
the commitment

A p95 under 1 second, publication to reception

Real time is the differentiator, so it has to be a number rather than an adjective — and nobody in this sector publishes one. The table is set by the one hazard in the vocabulary that moves: a queue tolerates a slow update, a wrong-way vehicle does not.

Measure it yourself

The instrument on the home page publishes an event and times the delta coming back down the stream — one clock, in your browser, for both readings, and the span includes that site’s own server hop on top of everything Relay does. It reads high relative to Relay’s own publish-to-receive figure, never low.

Publish one and watch the rail

On the reference stack

min
36.2 ms
p50
53.9 ms
p95
73.0 ms
commitment
1 000 ms

Fifteen publish-to-receive measurements on the reference stack — a thirteen-fold margin under the design target. Production topology adds a message bus and network hops inside that margin.

continuous checks

A job publishes into the sandbox every five minutes

The page you are reading probes the API when somebody opens it. The canary probes it whether anybody is looking or not, and it exercises the write half — which no read-only check can reach.

  1. Publishes

    One event into each of three watched areas, with a sandbox key — DNS, TLS, bearer authentication, metering and the geohash write, against the deployed revision.

  2. Reads back

    Each event through the area query at the same 8 km radius a subscriber uses, which is the cell fan-out and the in-memory expiry filter doing their jobs.

  3. Confirms

    One of the three from two more vehicles, so the reporter quorum promotes it — the only thing in production that exercises the signal route end to end.

  4. Mirrors

    Both writes land in the analytical copy, so the warehouse schema is checked by traffic rather than by a migration script.

It runs in the sandbox environment on purpose, and every tick re-checks the environment it gets back: a canary key issued live would publish synthetic incidents into every partner’s feed with nothing downstream objecting. Canary events are excluded from the analytical figures by their organisation.

planned work

Maintenance and breaking changes

The wire contract is additive forever, so there is no such thing as a breaking release of it. What can affect you is planned maintenance, and it is announced to the contact address on your account rather than only here.

No maintenance is scheduled. Vocabulary additions and platform changes are dated in the changelog, and the rules a client must follow to survive them — ignore unknown fields, skip unknown values — are in the compatibility reference.