Server activity feed

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

Returns a timeline of failures and key events for a server: undelivered Bitrix24 events, bot delivery problems, deployments, wake-ups and status changes.

Call this first when an application has stopped working, a bot is silent, a Bitrix24 event did not arrive or a deployment failed: an entry names the cause as a machine-readable code, and an entry about a deployment or a command leads to its outcome. The feed does not record API call errors, events polled by a bot, or successful deliveries, so an empty feed does not prove that events were delivered.

The feed is read by the server owner with a personal key or with the key of their own OAuth application from the same Bitrix24 account, and by a development team member whose role includes server settings, with their own personal key. An OAuth application key reads the feed with the rights of its owner: the session user does not affect access, and the session token can be omitted. Keys issued for a narrow task with their own list of routes (an agent maintenance key, an application external API key, a team member key and an external collaborator key) do not read the feed and get 403 with a code of the form …_KEY_OUT_OF_SCOPE. For everyone else, including a Bitrix24 account administrator without a role in the team, the server responds as if it did not exist.

Parameters

An empty parameter value counts as passed: ?severity= gives 400 INVALID_SEVERITY, not all severities.

Pages. Entries go from newest to oldest by time of first appearance. While the response contains a non-empty nextCursor, pass it unchanged as the cursor parameter in the next request. null means the last page.

Examples

curl — personal key

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

curl — OAuth application

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

JavaScript — personal key

const res = await fetch(
  `https://vibecode.bitrix24.com/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(`  details: /v1/infra/servers/${serverId}/operations/${e.ref.id}`)
  }
}

JavaScript — OAuth application

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

Response fields

Entry kinds:

meta.trigger — who woke the server: manual, api, deploy, gateway, auto-wake-on-preempt, auto-wake-on-unfreeze, scheduled. meta.from and meta.to are server statuses in lowercase, as in GET /v1/infra/servers/:id. meta.reason of a status change equals billing_freeze when a running server was put to sleep by a balance freeze; otherwise the field is absent.

Response example

{
  "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
  }
}

Error response example

404 — the server does not exist, is unavailable to this key, or the feed is not enabled for the server owner:

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

Errors

The full list of common API errors is in Errors.

Known specifics

• A repeat does not create a new entry. Identical server events within one five-minute window are merged into one entry: count grows and lastAt moves. Windows are aligned to five-minute UTC boundaries: 12:10–12:15, 12:15–12:20 and so on. The entry does not move to the top of the feed; the order is kept by firstAt, so paging through nextCursor has no gaps or repeats, even if the server keeps failing while you read the feed. The exception is a status change inside a long operation, see below.
• firstAt is the moment of writing to the feed, not of the event itself. An entry appears a few seconds after the event: the deployment in the response example finished at 12:13:28, and its entry is dated 12:13:32.
• A wake-up is visible through status changes. A sleeping standalone virtual machine wakes through the chain sleeping → provisioning → running, while a Galaxy application goes straight from sleeping to running. A wake.succeeded entry appears only after a blocking wake-up that waited for the server to come up. A non-blocking wake-up leaves only status changes in the feed.
• The code in a deployment entry is not the top-level code of the deployment response. The response of POST /deploy carries error.code: "DEPLOY_FAILED" when a step fails, and the step cause in error.causeCode. A deploy.failed entry carries the same code as error.code of the operation outcome: the step cause if it is known, for example DOWNLOAD_HTTP_STATUS when a download fails, DEPLOY_STEP_FAILED if the step failed without a named cause, and DEPLOY_FAILED on a failure of the platform itself.
• The deployment error text is not stored in the feed, only the code. The message and the step are read by ref.id through GET /v1/infra/servers/:id/operations/:operationId, while the platform retains the outcome (7 days).
• History depth. Entries are kept for 30 days. Status changes are recorded for every server. Other entries are recorded from the moment the feed was enabled for the server owner, so for a while after that the history can be shorter than 30 days.
• A status change can appear below an already read page if the status changed inside a long platform operation: the entry carries the start time of that operation. The next read of the feed from the first page will show it.
• The feed belongs to the server. After a server is transferred to another owner, the new owner sees the entries made before the transfer, and the previous one gets 404.

See also

• Operation outcome from the server feed
• Get a server
• Recent server operations
• Service logs
• Bitrix24 event subscriptions
• MCP