AffixIO service status

It measures your path, not a global one

The checks run from the browser you are reading this in. That is deliberate: a status page maintained by the same estate it reports on will happily tell you everything is fine while a region is dark. Measuring from the client puts your DNS resolver, your network and your TLS path inside the test, which is usually where the problem is when the service itself is healthy.

The cost is that a red row does not automatically mean an outage. A corporate proxy, a blocked request or a dead connection on your side produces the same result as a service that is down. Before escalating, run the same check from a second network. If one passes and the other fails, the fault is on the path rather than at our end.

Two levels of detail

Where the endpoint grants cross-origin read permission to this page, the check reads the response and asserts on real fields: status equal to ok, algorithm equal to ML-DSA-65, and so on. Where it does not, the check falls back to an opaque request that proves the host answered and times the round trip without seeing the body. Each row states which of the two it got, so a thin row is a permissions boundary and not a hidden failure.

Be clear about the limit of the second one. An opaque request cannot tell a 200 from a 403, because the browser hands back an empty response either way. A row marked reachable therefore means the host answered, not that it answered correctly. If a call of your own is failing while every row here reads reachable, run the commands below from a terminal: those see the status code and will show you what the browser was not allowed to.

Latency is indicative

Timings include DNS, TLS and your own network, and they are taken from a single request rather than a percentile over a window. Treat them as a smoke test. Use the X-RateLimit-* and x-request-id response headers on your own calls when you need to reason about real API behaviour under load.

This page is not a monitoring dependency

It is static HTML with no server-side logic, deliberately the simplest thing on the estate so it survives a failure of the services it reports on. Do not have your alerting parse it. Point alerts at https://api.affix-io.com/api/health and keep this page for people.

The one check worth alerting on

Fails loudly on a non-2xx, a timeout, or a health document that does not say ok.

curl -fsS -m 10 https://api.affix-io.com/api/health \ | jq -e '.status == "ok"' > /dev/null

Everything the health document gives you

Public, uncached, and the fastest way to identify which build answered.

curl -fsS https://api.affix-io.com/api/health | jq '{ status, service, engine, policy_version, circuit_count, merkle_root, merkle_leaf_count }'

Attestation signing

Assert on the algorithm as well as the status code. A 200 carrying the wrong algorithm is not a pass.

curl -fsS -m 10 https://api.affix-io.com/v1/attestation/public-key \ | jq -e '.algorithm == "ML-DSA-65" and (.key_id | length) > 0'

Key enforcement, by hand and not on a timer

A keyed route should refuse an unauthenticated request, so this returns 401 and a 200 would be the finding worth paging someone for. Run it when you want to confirm the auth layer, then stop.

test "$(curl -s -o /dev/null -w '%{http_code}' -m 10 \ https://api.affix-io.com/v1/health)" = "401"

Do not put that one in a monitoring loop. Unauthenticated requests to keyed routes are counted as authentication failures, and enough of them will get your address temporarily blocked from the whole API. A recurring check built on it eventually causes the outage it was meant to detect, and on a shared office address it takes your colleagues with it. Recurring checks belong on the unauthenticated routes above.

Keeping the component list in sync

The registry this page renders from is published as JSON, with the probe URL and expected response for each component. Read it rather than hard-coding a list that drifts.

curl -fsS https://status.affix-io.com/components.json \ | jq -r '.groups[].components[] | "\(.id)\t\(.probe)"'