# Status and incidents

> How route health is checked and what the public status page shows.

Source: https://cairva.xyz/docs/status-and-incidents

The public [status page](https://cairva.xyz/status) shows the health of every route and any incidents Cairva operations have posted. It only shows facts backed by Cairva's own records, with the time window stated.

## Route health

Cairva's background worker checks each route on a schedule by calling the route's `/models` endpoint and confirming its model id is listed. Each check records:

| Field | Meaning |
| --- | --- |
| Health | `healthy` if the model is listed, `down` if the call failed or the model is missing, `unknown` before the first check |
| Last checked | When the latest check ran |
| Latency | How long that check took |

A route is also checked once more whenever an agreement on it tries to activate, and the agreement only activates if that check passes.

For each route the status page also shows the model, region, mode (`live` or `sandbox`), whether operations have it enabled, and how many requests it handled in the last 24 hours and how many of those succeeded.

## Incidents

Cairva operations post incidents when something affects delivery.

| Field | Values |
| --- | --- |
| Severity | `minor`, `major`, `critical` or `maintenance` |
| Status | `investigating`, `monitoring` or `resolved` |

Updates are appended to the incident with a UTC timestamp, so the history stays readable. An incident can be tied to one route.

## When a route is down

- Requests can fail with `502 upstream_error`. The hold is released and nothing is charged.
- If operations disable the route, requests fail with `502 route_disabled`.
- Agreements on the route can't activate until it's healthy again.

If an outage cost you capacity you'd agreed to, open an `availability` dispute on the agreement. See [Agreements](https://cairva.xyz/docs/agreements#disputes).