Repair status

GET /v1/infra/servers/:id/repair-status

Returns the progress of a background tunnel repair started via POST /repair. Used for periodic polling: the client sees the current step (wake / serial_console / ssh_install / connect / …), the final status (running / done / failed), and, in case of an error, the error field. Completed records are cleared automatically after 10 minutes.

Parameters

Examples

curl — personal key

curl -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/repair-status

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/repair-status

JavaScript — personal key

// Progress polling loop
while (true) {
  const res = await fetch(
    `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/repair-status`,
    { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
  )
  const { data } = await res.json()

  if (data.status === 'idle') { console.log('Repair not started'); break }
  if (data.status === 'done')  { console.log(`Done, step: ${data.step}`); break }
  if (data.status === 'failed'){ console.error(`Error at step ${data.step}: ${data.error}`); break }

  console.log(`Step: ${data.step}`)
  await new Promise(r => setTimeout(r, 10000))
}

JavaScript — OAuth application

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

Response fields

For status: "idle", only the status field is returned; the remaining fields are absent.

Response example

Repair not started:

{
  "success": true,
  "data": {
    "status": "idle"
  }
}

Repair in progress, agent installation step completed:

{
  "success": true,
  "data": {
    "status": "running",
    "step": "connect",
    "agentVersion": "1.2.3",
    "wasSlept": false,
    "startedAt": 1745312400000
  }
}

Repair failed:

{
  "success": true,
  "data": {
    "status": "failed",
    "step": "ssh_install",
    "agentVersion": null,
    "wasSlept": false,
    "error": "SSH connection refused",
    "startedAt": 1745312400000
  }
}

Error response example

404 — server does not exist:

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

Errors

Full list of common API errors — Errors.

Known specifics

• Step execution order: wake (if the server is sleeping) → serial_console (inject the SSH key via the Bitrix24 Cloud serial console) → ssh_install (SSH connection and agent reinstall: download the binary, write the configuration, start the service) → connect (wait for the agent to connect to the Gateway) → iptables (restore the firewall for BLACKHOLE) → cleanup (return to sleeping if the server was sleeping) → done.
• Right after POST /repair the status is already running, not idle. The status is set to running synchronously when the repair starts, so the very first repair-status poll (even milliseconds later) sees running. Previously there was a brief window where a poll could see idle and the poll loop exited prematurely — that window is now gone.
• TTL of completed records — 10 minutes. After that, a repeat poll returns idle. If you need to confirm the result after the TTL, look at blackholeStatus in GET /v1/infra/servers/:id — if it is CONNECTED, the repair worked.
• Concurrent repair is impossible — there is an in-memory repairingServers lock at the service level. A repeat POST /repair on a server with a repair already in progress is handled correctly: the second call does not start a new procedure.

See also

• Repair the tunnel
• Get the server
• Refresh status