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. Repeating the log read in a loop while the app sleeps 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.

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