# Tyxter Status

> Machine-readable status for the Tyxter Messaging API. The feeds below are JSON, need no authentication, and are the same data the status page renders.

## Feeds

- [Current health](https://api.tyxter.com/status): served by the API itself. `status`, `components.db` and `components.redis` are `healthy`, `degraded` or `down`. It cannot answer while the API is down.
- [Uptime and last probe](https://uptime.tyxter.com/uptime.json): an external probe checks current health every 5 minutes from outside Tyxter's infrastructure. `latest` is the most recent probe (`checked_at`, and `result`: `up`, `degraded` or `down`); `days` holds 90 UTC days of counts. It keeps answering during an outage.
- [Incidents](/incidents.json): published incidents, active and resolved. Each has `id`, `title`, `status` (`investigating`, `identified`, `monitoring` or `resolved`), `impact` (`none`, `minor`, `major` or `critical`), `started_at`, `updated_at` and `summary`. Sort by `updated_at`.

## Reading them together

1. Read current health. `healthy` means the API is accepting work now.
2. If it fails or times out, read the uptime feed. A `latest.result` of `down` with a recent `checked_at` means Tyxter is down, not your network. If `checked_at` is more than 20 minutes old, the probe has stalled: treat its answer as unknown, not as up.
3. Read incidents for the explanation and timeline. An incident whose `status` is not `resolved` is ongoing.