Galaxy app sleep and wake

A Galaxy app goes to sleep when idle, together with the galaxy that carries it, and while it sleeps its container is stopped. This page describes what exactly stops, which fields report the real state, how to bring the app up and how long that takes.

What stops · State fields · How to bring it up · Logs · Recurring wake window

What stops during sleep

The app runs in a container on a shared host — the galaxy. Both parts can sleep, and these are different states.

The persistent /data volume survives sleep. Waking starts the same container instead of creating a new one, so the lines the app wrote to its output stream before it slept are available after the wake too. A fully new container appears only on the next code upload, and that upload does not keep the previous container's log.

The status and reachability fields answer different questions

The status field in the GET /v1/infra/servers/:id response is the state of the app's record on the platform. A wake moves the record to running at the end, once the container is already started, so while the galaxy is coming up the record stays sleeping — on a cold machine that takes minutes. The opposite divergence is possible as well: the record can read running while the container is no longer working.

That is why the reachability block sits next to it — it answers the question "can the app respond right now". The block is present only for an app whose kind is GALAXY_APP; for every other server type it is null.

{
  "success": true,
  "data": {
    "id": "e22bb297-8a0a-4597-9b42-47d059cd1090",
    "kind": "GALAXY_APP",
    "status": "sleeping",
    "reachability": {
      "effectiveStatus": "running",
      "hostStatus": "running",
      "hostTunnel": "CONNECTED",
      "container": "running",
      "forwarder": "active",
      "publicEntry": "live",
      "probe": "ok",
      "probedAt": "2026-08-12T13:24:58.117Z"
    }
  }
}

Only the sleep-related fields are shown. For the full response, see GET /v1/infra/servers/:id.

How effectiveStatus is derived:

The public entrance is checked separately. The container and the routing are measured on the galaxy itself, while the last leg of the path to https://app-XXXX.vibecode.bitrix24.com is the app's tunnel at the gateway, which is invisible from the galaxy: a started routing unit means it was started, not that it reached the gateway. So an app with a live container and active routing but no tunnel answers unreachable rather than running — that address serves nothing from outside. When the gateway's state could not be read, publicEntry is unknown and the verdict stays as it was: "could not look" is not "nothing works".

Important: the platform runs the live host check only while the galaxy is up and connected to the platform. Reading state never wakes a sleeping galaxy, so for a sleeping galaxy container and forwarder are always unknown and probe is host-down. The platform keeps the check result for a few seconds and serves it from memory: a check occupies the command channel shared by every app of the galaxy, so, thanks to this cache, frequent state polling does not tie it up.

How to bring a sleeping app up

The wake call returns immediately, not when the app is ready: an app has no cloud machine of its own, and the ?wait=true parameter does not make the call wait here. Check readiness by polling GET /v1/infra/servers/:id and reading reachability.effectiveStatus — the value waking means the galaxy is still booting.

How long to wait: the platform waits up to 15 minutes for a cold galaxy to come up, and expects the caller to wait as long. The exact budget is returned in the recovery.coldBootBudgetSeconds field when you read the logs of a sleeping app. An app on a galaxy that is already up starts in seconds.

A wake ban on the host blocks both calls, and /start does not lift it. The refusal codes are in the lifecycle table on the Galaxy app page.

When the app address has no tunnel, a confirmed wake ban is handled separately. Only in PUBLIC mode does the Gateway return 409 BH_APP_UNAVAILABLE without Retry-After: browsers show "App temporarily unavailable" and a "Refresh" button, while machine clients get JSON. The reason for the ban, balance information and platform brand are not disclosed, and neither waking nor automatic polling starts. An already open waiting page switches to this screen on its next poll. Once the ban is lifted, open the app again manually. In private mode, an identified user still receives 402 BH_WAKE_BLOCKED.

Logs of a sleeping app

Reading GET /v1/infra/servers/:id/logs wakes neither the app nor the galaxy. While the galaxy is asleep or unreachable, the response arrives with status 200, an empty data.logs array and two diagnostic fields.

{
  "success": true,
  "data": {
    "logs": [],
    "lines": [],
    "hint": "Galaxy host is asleep or unreachable, so the container log cannot be read right now. …",
    "recovery": {
      "reason": "The galaxy host carrying this container is not RUNNING + CONNECTED. …",
      "recoveryAction": "POST /v1/infra/servers/e22bb297-8a0a-4597-9b42-47d059cd1090/wake",
      "logsPreserved": true,
      "coldBootBudgetSeconds": 900,
      "poll": "GET /v1/infra/servers/e22bb297-8a0a-4597-9b42-47d059cd1090 (read `reachability`)",
      "wakeSchedule": { "available": true, "code": null }
    }
  }
}

The sequence: bring the app up with the call from recovery.recoveryAction, wait until reachability.effectiveStatus is running, then read the logs again.

If the response carries no recoveryAction, the wake is refused. The cause is of one of two kinds, and hint names the one that applied: either a door of the caller itself (the list below), or a wake ban on the galaxy HOST — there the key is irrelevant, every caller is refused, and it is the account owner who lifts it. The wake call answers 403 SERVER_WAKE_BLOCKED in that state, and 402 with the subscription or plan wall code while the account's access is still lapsed. A recurring wake window can still be created in that state, but it will not bring the host up: the ban applies to a scheduled wake as well. There is no wake address in the prose either — in that state the answer deliberately names neither POST …/wake nor the creation of a scheduled window, which the same door refuses. Instead of an address, hint names exactly the condition that applied to this caller rather than a list joined by "or" — and it names the FIRST one in the order the doors actually refuse. That order is: an agent maintenance key does not carry the wake in its route allowlist; a pending account deletion closes the wake entirely, and changing the key does not help — the owner is frozen, not the key (delivery stays open there, see the second path below); the key mode is changed as described in Access mode; a Cowork/Code key has no access to the control plane at all; a disabled galaxy pilot is switched back on by the Bitrix24 account administrator; and last, reaching the app through its application link while another key owns the server: the wake checks ownership more strictly than the log read, so such a caller gets 404 and only a call by the server's owning key helps.

Some callers do have a way out, and it is not a wake. A key in read-only mode is allowed to deploy to a server it owns, and a deploy to a sleeping galaxy app brings the host up by itself. The same path is open to two more callers who are refused the wake: an owner whose account deletion is pending (the freeze sits on the /v1/infra plugin, while delivery lives in another one) and a caller admitted through the application link (delivery checks ownership more loosely than the wake). It is closed to exactly three: a Cowork/Code key, an agent maintenance key, and a caller on an account with the galaxy pilot switched off. When that path is open the platform exposes it in machine-readable form — the recovery.deliveryWakesHost field (action is the call, cost states the price in words) — and the price is not a formality: it is a code deployment and it spends the Vibecode balance, not a wake. Do not call it just to read a log.

It is not open to everyone, and the field is what tells you. The read-only carve-out lifts the ACCESS-MODE gate on deploys and nothing else. A Cowork/Code key has no access to the control plane at all, a disabled galaxy pilot refuses every non-GET in this family, and an agent maintenance key does not carry the deploy in its route allowlist — all three are refused POST …/deploy exactly as they are refused the wake. So check for deliveryWakesHost rather than assuming it: no field means no open path, and the condition named in hint is what has to change. Important: the converse is not guaranteed either, exactly as with recoveryAction: the field's presence means the deploy is refused neither by identity and key mode nor by a ban on the host. It does not answer for the state of the account AT THE MOMENT OF THE CALL: a balance freeze closes the whole /v1/infra family (402 ACCOUNT_FROZEN), and if it arrives after this read, the action it names gets exactly that — all the more so because a deploy spends balance by construction. Until the condition changes, repeating the log read in a loop is pointless: the answer stays the same.

Recurring wake window

A wake window brings the app up on a schedule, without a manual call. It is not available to every app, so check this against the platform's answer rather than a general rule: the recovery.wakeSchedule field in the response to a log read of a sleeping app gives a direct answer for that particular app and, on a refusal, the refusal code.

That answer is about the app and about the caller at once. Creating a window is still a write, so it is refused to a key in read-only mode, to a Cowork/Code key, and on a Bitrix24 account with the galaxy pilot switched off; in those states the field comes back available: false with the code of the door that refused. Wake availability is a good first signal — no recovery.recoveryAction means that caller cannot create a window either — but it is not the whole answer, because the window has two doors the wake does not: the route is outside the allowlist of an external collaborator key (EXTERNAL_COLLABORATOR_KEY_OUT_OF_SCOPE), and it requires the vibe:infra scope, which waking does not (INFRA_SCOPE_REQUIRED). Either one refuses the window even to a caller who can wake the app, so read recovery.wakeSchedule itself rather than deriving it from recoveryAction.

An app in a galaxy never gets the ALWAYS_ON_CONFLICT refusal: it does not choose its plan but inherits it from the galaxy, and the platform does not treat it as running in always-on mode. This also covers agents and bots: they have no idle timer of their own, but a wake window is available to them on the usual terms. The window's other refusals still apply — for example, WAKE_SCHEDULE_GALAXY_DISABLED when the capability for Galaxy apps is switched off on the platform.

Listing, creating, updating and deleting windows — Scheduled wake.

See also

• Galaxy app
• Wake a server
• Server logs
• Get a server
• Scheduled wake
• Authorization in a Black Hole app