Wake-on-join and hibernation

A metered or free-plan server with nobody playing hibernates automatically. Its container stops, and on 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 of those, never flat.

Why it sleeps

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

A paid server stopped for 60 days

From December 1, 2026, a paid (metered or flat) server that hasn't run for 60 days may be deleted. The 60 days count from when it last ran. We email the owner at least 7 days before; starting it in that time keeps it, and starting needs a positive wallet balance. If it can't start for a reason on our side, contact support before the date in the email and we'll keep it. A final backup of its files is kept, and support can restore it; the wallet balance isn't touched. See the Terms, section 5.

Turning join-triggered wake off

Settings → Wake on join has one toggle: "Allow players to wake this server by joining." Its description reads: "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 a message telling them a server operator has to start it, and no wake is attempted. A status ping (seeing the server in the multiplayer list) never wakes a server, whether this toggle is on or off.

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". It takes 0 to 1440 minutes, where 0 means the platform default (currently 8 minutes). You might look for it next to the wake-on-join toggle, but 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 picks it up before its next restart depends on which physical node it's on, and the panel doesn't show you that. Treat it like the rest of the Properties tab: assume the change takes effect on the next restart, not the moment you click Save.

What 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 wake-kick message ("Still waking up. Rejoin shortly") leaves the time open on purpose, because how long a wake takes varies by world and core.

What we've 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 one measurement we rely on comes from a manual, external test on 2026-08-08 (dial → first byte, through the 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 described below. It also matches the phase breakdown measured in the same test: roughly 9–10 seconds of container startup before the Minecraft process begins, with the rest depending on world and core.

A second figure, for a Paper server on na-2, was measured the same way and used to appear here as ~20.3 seconds. We removed it because it's very likely not a wake time at all. The test tool only checks whether any byte comes back on the socket and counts that as a successful join; it never reads what the byte is. The proxy's login-hold kick (below) writes to that same socket, at a fixed 20-second timeout, whenever a wake is still in progress past that point. The same test's 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 ready to accept players; an open network port isn't enough. 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, so that byte cannot have come from the backend. Measuring na-2's wake time properly would need a tool that reads past the first byte and confirms it's a login-success response from the backend rather than a disconnect packet. That tool doesn't exist yet, so we have no number for na-2 until it does.

The login hold timeout is a separate, fixed mechanism. It isn't a wake measurement, and it doesn't depend on the node. 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. A different mechanism can make the wait much longer than 20 seconds: 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. The panel doesn't show which of the two you get, but the 20-second figure doesn't vary by node.

Troubleshooting

A player says joining didn't wake the server. Check whether wake-on-join is off (see above); in that case the kick message says so. If it's on, the server may have failed to start (its page in the panel shows why), be in a cooldown after a recent failed start, or be slow to start. Each of those has its own kick message. There's also an anti-abuse rate limit on repeated cold wakes from the same source IP, which bounds how often an unauthenticated source can force wake attempts. Past that limit, joins from that IP that would wake a sleeping server are refused for a while. Players who share one public IP share the limit, and players joining through a server network's proxy share the proxy's. The refused player is kicked with a message saying so. If a specific player or IP keeps getting that message, the rate limit is a 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, where the longer in-game wait is used instead, longer than that). That's expected on a heavier world or core. The wake keeps going in the background, and 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 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 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.