Лента событий сервера

GET /v1/infra/servers/:id/activity

Возвращает хронологию сбоев и ключевых событий сервера: недоставленные события портала, проблемы доставки боту, выкладки, пробуждения и смены статуса.

Звать первой, когда приложение перестало работать, бот молчит, событие портала не пришло или выкладка упала: запись называет причину машинным кодом, а запись о выкладке или команде ведёт на её исход. Лента не записывает ошибки вызовов API, бота, который сам забирает события запросами, и успешные доставки, поэтому пустая лента не доказывает, что события дошли.

Ленту читает владелец сервера личным ключом или ключом своего OAuth-приложения из того же портала и участник команды разработки, чья роль включает настройки сервера, — своим личным ключом. Ключ OAuth-приложения читает ленту правами своего владельца: пользователь сессии на доступ не влияет, а токен сессии можно не передавать. Ключи, выданные под узкую задачу со своим перечнем маршрутов, — ключ обслуживания агента, ключ внешнего API приложения, ключ участника команды и ключ внешнего участника — ленту не читают и получают 403 с кодом вида …_KEY_OUT_OF_SCOPE. Остальным, включая администратора портала без роли в команде, сервер отвечает так же, как несуществующий.

Параметры

Пустое значение параметра считается переданным: ?severity= даёт 400 INVALID_SEVERITY, а не все важности.

Страницы. Записи идут от новых к старым по времени первого появления. Пока в ответе приходит непустой nextCursor, передавайте его в cursor следующего запроса без изменений. null означает последнюю страницу.

Примеры

curl — личный ключ

curl -H "X-Api-Key: YOUR_API_KEY" \
  "https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/activity?limit=20"

curl — OAuth-приложение

curl -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  "https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/activity?limit=20"

JavaScript — личный ключ

const res = await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/activity?limit=20`,
  { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
)
const { data } = await res.json()

for (const e of data.events) {
  console.log(e.firstAt, e.severity, e.kind, e.code ?? '', e.count > 1 ? `×${e.count}` : '')
  if (e.ref?.type === 'deploy_operation') {
    console.log(`  подробности: /v1/infra/servers/${serverId}/operations/${e.ref.id}`)
  }
}

JavaScript — OAuth-приложение

const res = await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/activity?limit=20`,
  {
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)
const { data } = await res.json()

Поля ответа

Виды записей:

meta.trigger — кто будил сервер: manual, api, deploy, gateway, auto-wake-on-preempt, auto-wake-on-unfreeze, scheduled. meta.from и meta.to — статусы сервера строчными, как в GET /v1/infra/servers/:id. meta.reason у смены статуса равен billing_freeze, когда работающий сервер усыплён заморозкой по балансу, иначе поля нет.

Пример ответа

{
  "success": true,
  "data": {
    "events": [
      {
        "id": "0b6f5b0e-3c4d-4a51-9a53-3f1d2c7e8a10",
        "kind": "deploy.failed",
        "severity": "error",
        "code": "DOWNLOAD_HTTP_STATUS",
        "meta": {
          "step": "download"
        },
        "ref": {
          "type": "deploy_operation",
          "id": "cmop1abcdefghijklmnopqrs"
        },
        "firstAt": "2026-10-06T12:13:32.251Z",
        "lastAt": "2026-10-06T12:13:32.251Z",
        "count": 1
      },
      {
        "id": "5e2a7c41-9d8b-4f06-8e1a-6b0c4d9f2e33",
        "kind": "server.status_changed",
        "severity": "info",
        "code": null,
        "meta": {
          "to": "provisioning",
          "from": "sleeping"
        },
        "ref": null,
        "firstAt": "2026-10-06T12:13:28.740Z",
        "lastAt": "2026-10-06T12:13:28.740Z",
        "count": 1
      },
      {
        "id": "a3d9e2f7-6b1c-4e8a-b5d0-7c2f9e4a1b68",
        "kind": "server.status_changed",
        "severity": "info",
        "code": null,
        "meta": {
          "to": "sleeping",
          "from": "running"
        },
        "ref": null,
        "firstAt": "2026-10-06T12:13:28.367Z",
        "lastAt": "2026-10-06T12:13:28.367Z",
        "count": 1
      },
      {
        "id": "c71f04b2-8e5a-4d93-9f6e-2b8a0d5c3e17",
        "kind": "server.status_changed",
        "severity": "info",
        "code": null,
        "meta": {
          "to": "running",
          "from": "provisioning"
        },
        "ref": null,
        "firstAt": "2026-10-06T12:13:08.096Z",
        "lastAt": "2026-10-06T12:13:29.035Z",
        "count": 2
      }
    ],
    "nextCursor": null
  }
}

Пример ответа при ошибке

404 — сервера нет, он недоступен этому ключу или лента для владельца сервера ещё не включена:

{
  "success": false,
  "error": {
    "code": "SERVER_NOT_FOUND",
    "message": "Server not found"
  }
}

Ошибки

Полный список общих ошибок API — Ошибки.

Известные особенности

• Повтор не создаёт новую запись. Одинаковые события сервера в одном пятиминутном окне склеиваются в одну запись: растёт count, сдвигается lastAt. Окна выровнены по пяти минутам UTC: 12:10–12:15, 12:15–12:20 и так далее. Запись при этом не переезжает в начало ленты, порядок держится по firstAt, поэтому обход по nextCursor идёт без пропусков и повторов, даже если сервер продолжает сбоить во время чтения. Исключение — смена статуса внутри долгой операции, см. ниже.
• firstAt — момент записи в ленту, а не самого события. Запись появляется через несколько секунд после события: выкладка из примера ответа завершилась в 12:13:28, а её запись датирована 12:13:32.
• Пробуждение видно сменами статуса. Спящая отдельная виртуальная машина просыпается цепочкой sleeping → provisioning → running, Galaxy-приложение — сразу sleeping → running. Запись wake.succeeded появляется только после блокирующего пробуждения, которое дождалось подъёма сервера. Неблокирующее пробуждение оставляет в ленте только смены статуса.
• Код в записи о выкладке — не верхний код ответа выкладки. Ответ POST /deploy при провале шага несёт error.code: "DEPLOY_FAILED", а причину шага — в error.causeCode. Запись deploy.failed несёт тот же код, что error.code исхода операции: причину шага, если она известна, например DOWNLOAD_HTTP_STATUS при провале загрузки, DEPLOY_STEP_FAILED, если шаг провалился без названной причины, и DEPLOY_FAILED при сбое самой платформы.
• Текст ошибки выкладки в ленте не хранится — только код. Сообщение и шаг читаются по ref.id через GET /v1/infra/servers/:id/operations/:operationId, пока платформа хранит исход, — 7 суток.
• Глубина истории. Смены статуса записываются для каждого сервера с момента выпуска записи смен статуса, остальные записи — с момента, когда лента включена для владельца сервера. Записи хранятся 30 дней. В первые 30 дней после включения история короче.
• Смена статуса может появиться ниже уже прочитанной страницы, если статус менялся внутри долгой операции платформы: у записи время начала этой операции. Следующее чтение ленты с первой страницы её покажет.
• Лента принадлежит серверу. После передачи сервера другому владельцу новый владелец видит записи, сделанные до передачи, а прежний получает 404.

Смотрите также

• Исход операции из ленты сервера
• Получить сервер
• Последние операции сервера
• Логи сервиса
• Подписки на события портала
• MCP