Removing a server without dropping requests

Hetscale removes a server by taking it out of your load balancer first, waiting the node group’s drain window while the requests already open finish, then shutting the server down cleanly and deleting it. A server is never deleted while it is still a target of your load balancer.

What happens, step by step?

1. Out of the load balancer. The server’s phase becomes Draining. With the webhook adapter, your pipeline first receives a signed node.terminating event. Then Hetscale removes the server as a target: your load balancer sends it no new connections, and the open ones continue.
2. The drain window. Hetzner gives no signal when a removed target has no connections left, so Hetscale waits the window you set, counted from the confirmed removal.
3. Shutdown. Hetscale asks Hetzner for a graceful shutdown, so the operating system and Docker send your application SIGTERM and it can exit cleanly. It waits up to 60 seconds for the server to power off; a server still on after that is reported with an alert, and the removal goes on.
4. Delete. Hetscale records its intent, checks that the server is one of its own, and deletes it. The phase becomes Terminating, then Terminated.

Each step is an event on the group’s timeline, with its time. If Hetzner, the ownership check or an action refuses a step, the server is left as it is: nothing irreversible happens without a person.

How long is the drain window?

60 seconds by default, up to 300 seconds, set per group as “Drain window” under Advanced in the group’s settings.

As of September 2026, according to a Hetzner support answer that Hetscale’s own test confirmed, a Hetzner load balancer keeps a removed target’s open connections alive until they close or 5 minutes pass, then resets them. It sends the target no new connections, apart from a request that can still arrive in the first moments after the removal, which the drain window covers, and it gives no “drained” signal. Raise the window if your application serves long requests, uploads, downloads, WebSocket or SSE connections that must not be cut; a lower window makes scale-in faster, and connections still open when it ends are cut by the shutdown.

When in the hour does a server leave?

As of September 2026, Hetzner bills every started hour of a server, counted from its creation or from the start of the month in UTC, whichever is later, until it answers the delete. Hetscale starts a removal late enough in the hour that the delete is answered before the next billed hour begins, with a margin for the drain window and the shutdown. A server that can no longer make that boundary keeps serving until the same point in its next hour, as long as the load stays low: that hour is paid either way, so the server is free capacity until then. A scale-in can therefore take up to an hour to take effect, and a scale-out in the meantime takes back a server that is waiting instead of creating a new one.

The Servers page shows when a released server leaves: “Leaves at …, inside the hour already paid”.

The server to remove is chosen in this order: a server of the least preferred type first (a fallback type before your own: the last one in your list, or the dearest in the cheapest mode), then a server created since Hetzner’s price change of 15 June 2026 before one created earlier, which keeps its earlier price (in practice a seed you promoted), then the one whose billed hour ends soonest, then among equals the youngest server on an older release, then a server not spread across hosts, then a server in the highest placement group, then the youngest.

A server that a rollout replaces is the exception: it leaves through the drain window as soon as its replacement serves (Releases, rollouts and rolling back).

Which servers are never removed?

• The seed. Scale-in never selects it, and the ownership check refuses any delete of it, whatever its labels say. A seed you promote to a managed server can be removed, after every server created since 15 June 2026; promotion is never automatic, and a server deleted this way loses its earlier price.
• Every other server of yours in the group. The Servers page marks it “Yours”: protected, never deleted or replaced.
• Any server without Hetscale’s labels. Before every delete, Hetscale’s ledger, the server’s labels and its name must agree. A server outside the group is listed and never shut down or deleted; a labelled server missing from the ledger is quarantined with an alert and deleted only when you confirm it.
• A server in maintenance. Maintenance, set from the group’s controls for the group or for one server, keeps Hetscale from removing it for the time you choose.
• A server with delete protection on in Hetzner. Hetzner refuses the delete, and the server is left as it is.

What do pause and the emergency stop do to a removal in progress?

• Pause starts nothing new and changes no traffic: no new server, no new drain, and a released server that still serves keeps serving. A server whose removal has begun finishes leaving, through the shutdown and the delete, so its billed hours end as planned.
• Emergency stop holds everything, a server whose removal has begun included, until you lift it: no server is created or deleted. A server that is still serving keeps serving; a server that was already out of the load balancer waits out of traffic, and Hetzner keeps billing it. Lifting the stop lets Hetscale create and delete again, and resumes a pause that the stop set.

What does this not cover?

• When a server is removed, and why: When Hetscale adds or removes a server.
• A failed server, and when it leaves: What happens when a server dies.
• Requests longer than the drain window, and anything written to the server’s own disk, which is lost with the server.
• A server you delete yourself in the Hetzner Console: Hetscale notices that it is gone, alerts you, and the group fills the gap under its usual rules.
• Cloudflare Load Balancing’s own drain is planned.