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, a bot that polls for events itself, 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 carries a non-empty nextCursor, pass it in cursor of the next request unchanged. 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 yet 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 during reading. 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, a Galaxy application goes straight sleeping → 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. Status changes are recorded for every server since the status change recording was released; other entries, since the moment the feed was enabled for the server owner. Entries are kept for 30 days. In the first 30 days after enabling, the history is shorter.
• 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