Galaxy app sleep and wake

A Galaxy app sleeps on 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 — that one does not keep the previous container's log.

The status and reachability fields answer different questions

The status field of GET /v1/infra/servers/:id 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",
      "probe": "ok",
      "probedAt": "2026-08-12T13:24:58.117Z"
    }
  }
}

The fields related to sleep are shown. The full response — GET /v1/infra/servers/:id.

How effectiveStatus is derived:

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 frequent state polling does not occupy it.

How to bring a sleeping app up

The wake call answers immediately rather than on readiness: an app has no cloud machine of its own, and the ?wait=true parameter buys no waiting here. Check readiness by polling GET /v1/infra/servers/:id on 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 is ready to wait the same from the caller. The exact budget arrives in the response to a log read of a sleeping app, field recovery.coldBootBudgetSeconds. An app on a galaxy that is already up starts in seconds.

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

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": false, "code": "ALWAYS_ON_CONFLICT" }
    }
  }
}

The order of actions: bring the app up with the call from recovery.recoveryAction, wait for reachability.effectiveStatus to be running, repeat the log read.

If the response carries no recoveryAction, waking is refused to this caller. 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 switched per Access mode; a Cowork/Code key has no access to the control plane at all; a disabled galaxy pilot is lifted 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 is answered 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 names it for machines — 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. ⚠️ The converse is not guaranteed either, exactly as with recoveryAction: the field's presence only means the deploy is not refused by identity or key mode. Billing and tariff are separate axes this field does not cover, so the action it names may still answer 402 (balance exhausted, a plan is required) — all the more so because a deploy spends balance by construction. Until it does, repeating the log read in a loop buys nothing: the answer does not change.

Recurring wake window

A wake window brings the app up on a schedule, without a manual call. It is not available to every app, and this should be checked 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 the ready answer for that particular app, and its code on a refusal.

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. Waking 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 to a caller who can wake the app, so read recovery.wakeSchedule itself rather than deriving it from recoveryAction.

One refusal is worth knowing in advance. An app that does not fall asleep on idle by itself is treated by the platform as permanently running, and a window for it is refused with the ALWAYS_ON_CONFLICT code. That is how agents and bots in a galaxy are created: they are brought up not by an incoming request but by their own polling of the Bitrix24 account, so no idle timer is assigned to them. Such an app is brought up with the wake call.

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

See also

• Galaxy app
• Wake a server
• Server logs
• Get a server
• Scheduled wake
• App authorization on Black Hole