Service logs

GET /v1/infra/servers/:id/logs

Returns the logs of a BLACKHOLE server via the journalctl system utility, with filtering by line count, time window, and substring. By default a deploy creates the app.service unit, unless you specify another name.

Parameters

Examples

curl — personal key

# Application logs for the last hour with a filter on "error"
curl -H "X-Api-Key: YOUR_API_KEY" \
  "https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/logs?service=app&lines=100&since=1%20hour%20ago&grep=error"

# The whole system journal, last 10 lines (for debugging cloud-init)
curl -H "X-Api-Key: YOUR_API_KEY" \
  "https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/logs?lines=10"

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/logs?service=app&lines=50"

JavaScript — personal key

const params = new URLSearchParams({
  service: 'app',
  lines: '100',
  since: '30 minutes ago',
})

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/logs?${params}`,
  { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
)
const { data } = await res.json()
data.logs.forEach(line => console.log(line))

JavaScript — OAuth application

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/logs?service=app&lines=50`,
  {
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)

Response fields

Response example

{
  "success": true,
  "data": {
    "service": null,
    "logs": [
      "Apr 22 11:17:02 epd65hdv07p8g89c0c06 CRON[1406]: pam_unix(cron:session): session closed for user root",
      "Apr 22 11:17:27 epd65hdv07p8g89c0c06 vibe-agent[1098]: 2026/04/22 11:17:27 [exec] id= timeout=10s workdir=\"\" command=\"uname -a\"",
      "Apr 22 11:17:28 epd65hdv07p8g89c0c06 cloud-init[975]: Reading package lists..."
    ],
    "lines": [
      "Apr 22 11:17:02 epd65hdv07p8g89c0c06 CRON[1406]: pam_unix(cron:session): session closed for user root",
      "Apr 22 11:17:27 epd65hdv07p8g89c0c06 vibe-agent[1098]: 2026/04/22 11:17:27 [exec] id= timeout=10s workdir=\"\" command=\"uname -a\"",
      "Apr 22 11:17:28 epd65hdv07p8g89c0c06 cloud-init[975]: Reading package lists..."
    ],
    "requestedLines": 50,
    "returnedLines": 3,
    "since": null,
    "grep": null
  }
}

Error response example

400 — server in OPEN mode:

{
  "success": false,
  "error": {
    "code": "NOT_BLACKHOLE",
    "message": "Deployment API only available for BLACKHOLE servers"
  }
}

Errors

For the full list of common API errors, see Errors.

Known specifics

• A sleeping standalone virtual machine is woken by a journal read. If the server (kind: "STANDALONE") is in sleeping status, the platform starts the wake and waits for it within the same request — up to 6.5 minutes — and only then reads the journal. The client's request timeout must be longer than that window. For a Galaxy app, a read behaves differently — see the "Galaxy apps" section below. A sleeping server with a live plan-change operation (resize) returns 409 EXEC_BUSY before waking; wait for that operation to finish.
• Line format — exactly as journalctl emits it. Each line already contains the time, hostname, process name, and its PID — no extra processing on the client is needed. Output the lines as is.
• The grep filter is a plain substring, not a regular expression. For complex patterns, fetch more lines and filter on the client.
• The tunnel agent's logs are visible without service — under the name vibe-agent. They help find the cause when the application does not respond through the Deploy API.
• The 500-line limit is multiplied by the call cap. The lines bound applies to each request. The current request limit is returned in the x-ratelimit-limit header. Your actual ceiling is 500 × the value from that header. For a larger volume of logs, make several calls with different since values.

Galaxy apps

If the server is a Galaxy app (kind=GALAXY_APP), the endpoint returns the stdout/stderr of the application container itself (docker logs), not the host system journal. The service parameter does not apply to Galaxy apps.

• Reading does not wake the machine. While the galaxy host is asleep or unreachable, the response arrives with status 200, an empty data.logs array and two diagnostic fields — data.hint and data.recovery. Bring the app up with POST /v1/infra/servers/:id/wake and retry the request: the wake starts the same container, so lines written before the sleep stay in the log. A cold galaxy takes minutes to boot. Its boot budget arrives in the recovery.coldBootBudgetSeconds field, and readiness is checked by polling GET /v1/infra/servers/:id on the reachability.effectiveStatus field. For an explanation of all response fields and the steps to follow, see Galaxy app sleep and wake.
• since — a duration or RFC 3339, not a relative text form. For Galaxy apps since accepts only a duration in seconds, minutes, or hours — 10m, 2h, 24h — or an RFC 3339 timestamp such as 2026-06-24T10:00:00Z. For a one-day window, use 24h. The relative journalctl text forms ("1 hour ago", "10 minutes ago") are accepted only for Black Hole servers.
• The grep filter works the same way — a plain substring, filtered platform-side.

See also

• Full deploy
• Run a command
• Tunnel metrics