How fast is a scale-out

How fast a scale-out is comes down to its Time to Capacity: the time from the decision that asks for a server to the first healthy check of that server at your load balancer. No figure is published for it yet. Hetscale measures it on your own node group from your first Rehearsal on, and shows where the time goes.

What does Time to Capacity measure?

It starts at the decision that asks for a server: a scale-out, a healing, a Rehearsal, an approved proposal or a server count you set by hand. It ends when your load balancer reports the new server healthy for the first time, the moment it can take traffic.

The time Hetscale takes to notice the load, the detection time, is recorded on the decision and is never added into Time to Capacity: it follows from your policy’s window and thresholds, which you choose. An incident report after a healing shows the two side by side.

Where does the time go?

Each server’s Time to Capacity is split into phases, and each phase has its own line:

• Provisioning: Hetzner creates the server from your group’s snapshot.
• Booting: the server starts, and Hetscale waits a fixed boot grace before the next step.
• Deploying: zero for the snapshot adapter, whose snapshot already holds your application; your pipeline’s own time for the webhook adapter.
• Health checking: the server is a target of your load balancer until its first healthy check.

Any wait between the decision and the create has a line of its own as well, so no time is hidden inside a phase.

What can I change to shorten it?

Two things on your side are part of every scale-out:

• Your load balancer’s health check. A new server takes traffic only once the check passes, so its interval, timeout and retries count every time. The recommendation is an interval of 5 s, a timeout of 5 s and 2 retries; preflight flags a check that keeps a new server waiting more than a minute for traffic.
• Your snapshot’s size. The larger the snapshot, the longer Hetzner takes to create a server from it. Hetscale warns when a release is larger than 10 GB.

With the webhook adapter, your pipeline is the third: its time is measured and shown, and only your pipeline can shorten it.

Why does the first scale-out after a new release take longer?

The first servers Hetzner creates from a new snapshot take longer to provision than the ones after them. With the snapshot adapter every new release is a new snapshot, so take a new release before a peak, not during it. For peaks you know in advance, the onboarding case for campaign and e-commerce peaks shows how to schedule capacity ahead of them.

Where do I see it?

• The Rehearsal: your first measured Time to Capacity, phase by phase, with recommendations for the health check, the snapshot size and the drain window.
• The group’s Capacity & cost page: P50 and P95 of Time to Capacity, over the servers that did not wait for stock.
• An incident report after a healing: the replacement’s Time to Capacity with its phases, next to the detection time.
• The group’s timeline: every step as an event with its time, from the decision to “Receiving traffic”, which shows the server’s Time to Capacity with its phases.
• Prometheus (Pro and Team): the newest server’s Time to Capacity per node group (Prometheus).
• The monthly summary mail: the month’s median and P95 (Monthly summary).

Why is there no number on this page?

One number would not describe your group: it depends on your health check, your snapshot and, with the webhook adapter, your pipeline. When a figure is published, it will be a range per adapter, stated with the health-check setting it assumes and taken from Hetscale’s own measurements and the first customers’ Rehearsals. Until then, the number that counts is the one measured on your own servers.

What does this not cover?

• The time before the decision. How soon a scale-out starts follows from your policy’s window and thresholds; they are safety settings, and the detection time shows their effect.
• Waiting for stock. A server whose type was out of stock is left out of the P50 and P95 on the Capacity & cost page; the time your group was short of servers is shown there on its own.