Recent server operations

GET /v1/infra/servers/:id/operations

Returns recent deploy operations on a server started by the current API key, newest first. This is the recovery channel when the POST /deploy response is lost before the client receives an operationId — notably when a connection drops during a Galaxy application build.

The endpoint only reads the shared outcome record: it does not wake the server, repair the tunnel, or release a mutex. Server access matches deploy access, while rows are additionally filtered by the exact API key that started them. An application-linked key therefore sees only its own runs, and the shared galaxy host id does not expose its applications' runs. An owner can reconcile its operations after the server is soft-deleted.

Parameters

Example

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

{
  "success": true,
  "data": {
    "operations": [
      {
        "operationId": "clz9k2m4x0001qw8h3f7d2n5p",
        "serverId": "8f14e45f-ceea-467a-9c8d-2f1c5a6b7e30",
        "status": "running",
        "outcomeAvailable": true,
        "step": "build",
        "startedAt": "2026-08-26T09:14:22.117Z",
        "finishedAt": null,
        "error": null
      }
    ]
  }
}

Operation fields

A terminal outcome is retained for 7 days. The row then remains in the list for a while with outcomeAvailable: false, but its status, step, and error are no longer exposed. unknown is a stable terminal answer when the platform cannot prove the remote outcome, for example after GATEWAY_UNREACHABLE; an expired operation still marked running is also shown as unknown.

Safe recovery after a dropped connection

1. Do not redeploy blind. Find this key's recent operation in the list.
2. While it is running, wait and poll the list or the addressable endpoint every few seconds.
3. Use a confirmed succeeded or failed outcome. For unknown or no matching record, reconcile GET /v1/infra/servers/:id and the logs.
4. If a later request confirms EXEC_BUSY, first verify that the list has no running operation, then account for the server kind. For STANDALONE, you may call POST /v1/infra/servers/:id/unstick and repeat the read-only checks. A GALAXY_APP uses its shared host's exec channel: tenant unstick is unsupported; wait 30–60 seconds and contact support if EXEC_BUSY persists. After either recovery, reconcile the list, state, and logs again before redeploying.

A standalone deploy with a transport reason of GATEWAY_UNREACHABLE, DEPLOY_CONNECTION_TERMINATED, DEPLOY_TIMEOUT, or DEPLOY_TUNNEL_STALE, and post-drop Galaxy GALAXY_DEPLOY_INTERRUPTED or GALAXY_HOST_UNREACHABLE responses, carry this read-first sequence in error.hint. A Galaxy response in this state carries error.retryable: false: the dropped connection by itself proves neither success nor failure. The slot, container, and /data are preserved while the outcome is unknown — do not delete or recreate the app.

Errors

See also

• Outcome by identifier
• Deploy an application
• Application logs