# Довідник Status API

GET /v1/status: публічне зведення поточного стану кожного сервісу AfterPack і його щоденної доступності за останні 90 днів, дані, на яких працює status.afterpack.dev.

Source: https://www.afterpack.dev/uk/docs/status-api

[status.afterpack.dev](https://status.afterpack.dev) показує, чи працює кожен публічний сервіс AfterPack і яку частину кожного з останніх 90 днів він працював. Сторінка читає один endpoint, і ви теж можете його читати: зі скрипта моніторингу, дашборда або кроку CI, який має перечекати збій перед [збіркою Pro](https://www.afterpack.dev/uk/docs/builds).

## Endpoint

**`GET https://api.afterpack.dev/v1/status`**

Без ключа, без сесії і без тіла запиту. Будь-яке джерело (origin) може викликати його з браузера. Відповідь може кешуватися на 60 секунд (`Cache-Control: public, max-age=60`), тож опитування частіше ніж раз на хвилину нічого нового не повертає.

```bash
curl https://api.afterpack.dev/v1/status
```

## Як перевіряються сервіси

Монітор перевіряє кожен сервіс кожні 5 хвилин із мережі Cloudflare:

| Сервіс | Хост | Вважається робочим, коли |
|---|---|---|
| API | `api.afterpack.dev` | Health check відповідає `200` з `"status":"ok"`. |
| Вебсайт | `www.afterpack.dev` | Головна сторінка відповідає `200`. |

Сервіс стає `down` після 2 невдалих перевірок поспіль і знову `up` після першої успішної. Кожна перевірка враховується в доступність за день, зокрема й поодинока невдача, яка не перевела сервіс у `down`.

## Відповідь

```jsonc
{
  "status": "operational",              // overall, see below
  "checkedAt": "2026-10-20T09:15:02Z",  // latest check of any service
  "intervalSeconds": 300,               // time between two checks of a service
  "services": [
    {
      "id": "api",
      "name": "API",
      "host": "api.afterpack.dev",
      "status": "up",                   // up | down | unknown
      "since": "2026-10-18T22:40:01Z",  // when status last changed
      "uptime": 99.982,                 // percent over the 90 days
      "days": [
        { "date": "2026-07-23", "checks": 288, "uptime": 100 },
        // ... one entry per UTC day, oldest first, today last
        { "date": "2026-10-20", "checks": 112, "uptime": 99.107 }
      ]
    }
  ]
}
```

| Поле | Значення |
|---|---|
| `status` | `operational`, коли всі сервіси працюють, `partial_outage`, коли деякі не працюють, `major_outage`, коли не працює жоден, `unknown` до першої перевірки. |
| `checkedAt` | Коли відбулася остання перевірка, або `null` до першої. Значення, набагато старіше за `intervalSeconds`, означає, що зупинився сам монітор. |
| `services[].id` | Сталий ключ сервісу. |
| `services[].status` | `up`, `down` або `unknown` для сервісу, який ще не перевірявся. |
| `services[].since` | Коли сервіс востаннє запрацював або впав, або `null` до його першої перевірки. |
| `services[].uptime` | Частка успішних перевірок за 90 днів у відсотках, або `null`, якщо перевірок не було. |
| `services[].days` | Рівно 90 записів, по одному на день UTC. `uptime` дорівнює `null` у день без перевірок. |

Показники доступності округлюються вниз до трьох знаків після коми, тож день з однією невдалою перевіркою показує `99.652` і ніколи `100`. До цієї відповіді можуть додаватися поля; наявні поля зберігають своє значення, як і в усьому [Cloud API](https://www.afterpack.dev/uk/docs/cloud-api).

## Коли API недоступний

Цей endpoint обслуговує сам API, тож коли `api.afterpack.dev` не може відповісти, не може й `/v1/status`. Тоді сторінка статусу читає [статус Cloudflare](https://www.cloudflarestatus.com) і повідомляє, чи Cloudflare звітує про власну проблему. У скрипті обробляйте невдалий запит до `/v1/status` так само: як збій API.

## Далі

- [SLA, SLO і підтримка](https://www.afterpack.dev/uk/docs/sla): цільова доступність, яку вимірюють ці перевірки.
- [Довідник Cloud API](https://www.afterpack.dev/uk/docs/cloud-api): решта API і те, як він версіонується.
- [Збірки і CI](https://www.afterpack.dev/uk/docs/builds): що робить збірка Pro, поки API не працює.