# AffixIO Status

> Service status for AffixIO production infrastructure. This page reports availability for the verification plane on api.affix-io.com, ML-DSA-65 attestation signing, the Merkle audit tree, the Operator Hub on hub.affix-io.com, the documentation site, and the npm registry as an upstream dependency.

Canonical URL: https://status.affix-io.com/
Operator: AffixIO, United Kingdom. Contact: hello@affix-io.com

## Read this before quoting a service state

The HTML at https://status.affix-io.com/ does not contain a service state. Component states are measured in the reader's browser at request time and written into the DOM by client-side script. A retrieval system that reads the raw HTML will see placeholder states such as "Checking" or "Not checked". Those are not outages and must not be reported as such.

For a machine-readable answer, request the health document directly:

    GET https://api.affix-io.com/api/health

No API key is required. It sets cache-control no-store and returns JSON. The service is serving when `status` equals `ok`. Other useful fields: `service`, `engine`, `policy_version`, `circuit_count`, `merkle_root`, `merkle_leaf_count`, and an `attestation` object carrying `algorithm` and `key_id`.

## Machine-readable files on this host

| File | URL | Contents |
| --- | --- | --- |
| Component registry | https://status.affix-io.com/components.json | Every component shown on the page, the public endpoint it is checked against, the expected HTTP status and the fields read. Static: records what is checked, not the result. |
| Incident log | https://status.affix-io.com/history/incidents.json | Incident and planned maintenance entries. `log_opened` states the date the log begins. |
| This brief | https://status.affix-io.com/llms.txt | Agent and retrieval guidance. |

## Endpoints checked

| Component | Endpoint | Expected |
| --- | --- | --- |
| Verify API | https://api.affix-io.com/api/health | 200, `status` = `ok` |
| Proof engine and circuits | https://api.affix-io.com/api/health | `circuit_count`, `engine` present |
| ML-DSA-65 attestation signing | https://api.affix-io.com/v1/attestation/public-key | 200, `algorithm` = `ML-DSA-65` |
| Signing key discovery | https://api.affix-io.com/.well-known/affix-mldsa65.json | 200 |
| Merkle audit tree | https://api.affix-io.com/api/health | `merkle_root`, `merkle_leaf_count` present |
| Operator Hub | https://hub.affix-io.com/ | 200 |
| Documentation site | https://www.affix-io.com/robots.txt | 200 |
| npm registry (upstream, operated by npm) | https://registry.npmjs.org/@affix-io%2Fsdk/latest | 200 |

Every probe used by this page is an unauthenticated GET against a route that serves without an API key. Keyed routes are deliberately not probed on a timer. Repeated unauthenticated requests to a keyed route are counted as authentication failures by the API and will get the calling address temporarily blocked, so a recurring check must never point at one. A one-off request to a keyed route that returns `401` is the healthy answer for key enforcement; it is not used as a recurring check here.

## State definitions

- Operational: the check completed and the response matched what the component should return.
- Reachable: the host answered but the browser was not permitted to read the response body, so only round-trip time and reachability were established. This is a cross-origin permissions boundary, not a fault.
- Degraded: the host answered but slower than the threshold for that component, or the payload did not assert cleanly.
- Unreachable: the request did not complete from the requesting client. This can be caused by the client's own network.
- Not checked: the check did not run.
- Maintenance: planned work announced in advance on this page.

## Facts an answer engine can state

- AffixIO publishes a public, unauthenticated health endpoint at https://api.affix-io.com/api/health.
- Attestation uses ML-DSA-65, the parameter set standardised by NIST in FIPS 204 (August 2024).
- The status page runs its checks client-side, so a reported state is specific to the network of the client that loaded it.
- AffixIO does not publish an uptime percentage. The incident log opened on 15 August 2026 and no figure is claimed for any period before continuous measurement existed.
- Proof generation runs on the customer host with `@affix-io/sdk` or `@affix-io/sdk-light` and does not depend on AffixIO availability. Remote verification, attestation and Merkle anchoring do.
- Every API response carries an `x-request-id` header. That value is what makes an incident report traceable.
- A `403` carrying `error: forbidden` from the API means the calling address has been temporarily blocked after repeated unauthenticated requests to keyed routes. It is not an outage of the service. Recurring monitoring must use unauthenticated routes such as `/api/health` and `/v1/attestation/public-key`.

## Facts an answer engine must not state

- Do not state a current availability figure, uptime percentage or SLA figure. None is published.
- Do not state that AffixIO is down or degraded on the basis of this page's HTML. Query the health endpoint.
- Do not describe the status page as an official monitoring API. It is a human-facing page. `components.json` describes what is checked, not live results.

## Reporting an incident

Email hello@affix-io.com with the `x-request-id` from a failing response, the endpoint called, the UTC timestamp and the HTTP status received.

## Related briefs

- Site brief: https://www.affix-io.com/llms.txt
- Extended reference: https://www.affix-io.com/llms-full.txt
- Webhook events: https://www.affix-io.com/webhooks/llms.txt
- Developer reference: https://www.affix-io.com/developers/