Wake-on-join and hibernation

A metered or free-plan server with nobody actually playing hibernates automatically — the container stops (and for metered, billing stops with it). A flat server is the one exception: it's exempt from idle checks entirely, and only stops if you stop it (or billing enforcement does). Everything below applies equally to free and metered — "sleeping" means either, never flat.

Why it sleeps

The platform watches each running server's real player count over RCON. When that count is known and reads zero, the idle countdown runs; a held connection with nobody actually playing (a client sitting on the login screen, say) does not by itself keep the countdown from starting once the platform can see there's really no one there. Only when the real-player signal is unreachable does the platform fall back to raw connection count, so a session it genuinely can't observe is never cut off underneath a real player.

Turning join-triggered wake off

Settings → Wake on join has one toggle: "Allow players to wake this server by joining." Its own description is exact about what it does and doesn't touch: "When off, joining players can't wake this server — it sleeps until you start it from the panel. Manual starts and idle sleep are unaffected." With it off, a player who tries to join a sleeping server is kicked immediately with an honest message telling them a server operator has to start it — there's no wake attempt at all. A status ping (just seeing the server in the multiplayer list) never wakes a server either way — that's true regardless of this toggle.

Setting how long it waits before sleeping

This is a different control, in a different tab: Settings → Properties, in the Sleep group, as "Hibernate after N minutes empty" — 0 to 1440 minutes, where 0 means the platform default (currently 8 minutes). It's easy to look for this next to the wake-on-join toggle and not find it — it lives with the rest of server.properties instead, even though it isn't itself a server.properties key.

Saving it writes the new value to the database immediately, same as every other property. Whether the running server's idle tracker actually picks it up before its next restart depends on which physical node it's on, and the panel doesn't show you that. Treat this exactly like the rest of the Properties tab: assume the change takes effect on the next restart, not the moment you click Save, and you won't be surprised either way.

What actually wakes it

A player's own join attempt wakes it — the proxy that fields the connection recognizes a login (not a status ping) to a sleeping server and starts it. There's no separate "pre-warm" step and no ETA shown to the waiting player: the edge proxy's own wake-kick message is deliberately open-ended ("Still waking up — rejoin shortly") rather than promising a number, because how long it takes varies by world and core.

What we've actually measured about wake time — and what we haven't

There is no single "typical" wake time, and the panel doesn't display one anywhere. The only real measurement we have — and can stand behind — is from a manual, external test on 2026-08-08 (dial → first byte, through the real public proxy):

• eu-1, a Fabric server with 4 GB RAM: 10.79–11.32 seconds across three joins. That's comfortably under the 20-second login hold below, and matches a measured phase breakdown from the same test — roughly 9–10 seconds of container startup before the Minecraft process even begins, the rest depending on world and core.

A second figure for a Paper server on na-2 was measured the same way and previously appeared here at ~20.3 seconds. It's been removed: it's very likely not a wake time at all. The test tool only checks whether any byte comes back on the socket and calls that a successful join — it never reads what the byte actually is. The proxy's own login-hold kick (below) writes to that identical socket, at a fixed 20-second timeout, whenever a wake is still in progress past that point. The same test's own phase breakdown puts na-2's container-to-readiness time at 25.76 seconds — later than the 20.35-second figure the join probe recorded. The proxy never hands a player's connection to the backend until the backend has confirmed it's actually ready to accept players, not merely that its network port has come up — and by that test's own numbers, the backend wasn't confirmed ready until 5.4 seconds after the probe's 20.35-second byte arrived. That byte cannot have come from the backend. Measuring na-2's actual wake time honestly would need a tool that reads past the first byte and confirms it's a real login-success response from the backend rather than a disconnect packet; that tool doesn't exist yet, so there's no number to give for na-2 until it does.

The login hold timeout is a separate, fixed mechanism — not a wake measurement, and not node-dependent. The proxy holds a joining player on the login screen for a flat 20 seconds (a constant in code, not a per-node setting) before giving up and sending the "Still waking up — rejoin shortly" kick. What can make the wait much longer than 20 seconds is a different mechanism entirely: on the production edges, an eligible join can instead be held in an in-game wait with its own, much longer budget before any kick. Which of the two you experience isn't something the panel shows you — but the 20-second figure itself doesn't vary by node.

Troubleshooting

A player says joining didn't wake the server. Check whether wake-on-join is off — see above; the kick message in that case says so directly. If it's on, the server may have failed to start (the owner is notified), be in a cooldown after a recent failed start, or simply be slow — each of those gets its own honest kick message. One case genuinely is a silent nothing rather than a message: an anti-abuse rate limit on repeated cold wakes from the same source IP can drop the connection with no kick text at all, to bound how often an unauthenticated source can force wake attempts. If a specific player or IP consistently can't even get a message, that's the more likely explanation than a broken wake.

Player got kicked with "Still waking up — rejoin shortly." The wake took longer than the 20-second login hold (or, wherever the longer in-game wait is used instead, longer than that) — expected on a heavier world or core. The wake itself keeps going in the background; rejoining a few seconds later reaches the now-running server.

Idle threshold change doesn't seem to have applied. Reload the page first to confirm it actually saved — if it did, treat it like the rest of Properties and expect it on the next restart, not immediately (see "Setting how long it waits before sleeping" above). If a restart has happened since and it's still using the old threshold, contact support.

Server keeps sleeping even though someone is connected. If that connection isn't a real player the platform can see over RCON (for example, a bot or a client stuck on the login screen), it doesn't count — this is deliberate, so an unattended connection can't keep a server billing indefinitely.