Service logs

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

Returns the logs of a BLACKHOLE server via the journalctl system utility. Without the service parameter, the whole system journal is read (all services and system-wide messages). To read the logs of a specific systemd unit, pass service (by default a deploy creates app.service, unless you specify another name). Supports filtering by line count, time window, and substring.

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

Full list of common API errors — 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. If the server does not come up, 503 WAKE_TIMEOUT arrives and the server returns to sleeping, so a repeat request is safe. On a Galaxy app, a read behaves differently — see the "Galaxy apps" section below.
• 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. Useful for diagnostics when the application does not respond through the Deploy API. Simply do not pass the service parameter — you will see the whole system journal, including vibe-agent, cloud-init, and other system-wide messages.
• The 500-line limit combined with the cap of 10 calls per minute means you can read at most 5000 lines per minute. For a larger volume of logs, make several calls with different since values, staying within the limit.

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 boots in minutes, its budget arrives in the recovery.coldBootBudgetSeconds field, and readiness is checked by polling GET /v1/infra/servers/:id on the reachability.effectiveStatus field. Every response field and the order of actions — Galaxy app sleep and wake.
• since — a duration or RFC3339, not a relative text form. For Galaxy apps since accepts only a duration in seconds, minutes, or hours (10m, 2h, 24h) or an RFC3339 timestamp (2026-06-24T10:00:00Z) — use 24h for a one-day window. The relative journalctl text forms ("1 hour ago", "10 minutes ago") are accepted only for Black Hole servers — for a Galaxy app such a value returns 400 VALIDATION_ERROR.
• The grep filter works the same way — a plain substring, filtered platform-side.

See also

• Full deploy
• Run a command
• Tunnel metrics