Start observing

A node group starts in Observe: Hetscale reads your load balancer and the servers behind it and records what it would have done, without changing anything in your project. Open Projects → the project → Groups → Start observing.

What do I need first?

A connected project (Connect a project) with a Hetzner load balancer and at least one server behind it: Observe watches that load balancer and its targets. When there is none, the page says “Load balancer first”: create one with your server behind it, choose Read again on the project’s page, then start.

What does Hetscale ask?

What no read of the project can show, under “Your setup”:

• “What runs on your server?”
• “Where is the database?”
• “How do you deploy a new version?”
• “Which of these apply?”: “Cloudflare proxy”, “Two separate apps on two servers” or “Campaign traffic”, any of them or none.

Answering “Coolify” to “How do you deploy a new version?” starts a node group that copies the seed Coolify deploys to; Coolify keeps deploying there (Coolify).

Once the three questions are answered, the page maps your answers and the project’s latest read to one of the onboarding cases, with its fit, the time before Live and your part, and follows every answer you change. An app with its database and files on the server is not a fit, because a second server cannot serve it. Queue workers without a web front, or nothing running on Hetzner yet, is “Not yet”. With one server behind the load balancer, the page advises running two: with one, a failed server leaves a gap until its replacement is healthy.

Beside your part, Before Live lists in short three of the lines Go Live will ask you to confirm before the first release: no uploads, sessions or SQLite files on the server, cron and queue jobs that can run on every copy, and an application that starts on boot. With “Coolify” as the deploy answer, a fourth line reads “Coolify runs on another server”. Go Live asks for them in full. The list shows for every case on its way to Live, so the trial is the time to prepare them. A declined case and a “Not yet” case show none.

How do I start?

Choose:

• the Load balancer;
• the Seed server, the server Hetscale copies from when you go Live. Your other servers behind the load balancer join the group, protected, when they share its architecture and network zone and are in no other node group;
• a Group name;
• a Server name prefix. Servers Hetscale creates are named after it: hetscale-web-1, hetscale-web-2 and so on for the prefix web. Left empty, it comes from the group name, and it cannot be changed later.

Then Start observing. Hetscale reads the load balancer and its servers once more and writes nothing to Hetzner. It declines a load balancer that carries the label of Kubernetes’ cloud controller manager, and a seed that carries the label of its Cluster Autoscaler: Kubernetes rewrites such a load balancer’s targets, and a copy of such a node would join your cluster. The panel then links Hetscale vs Kubernetes on Hetzner; the API answers 422 kubernetes_managed.

A token with Change groups starts observing through the API as well, with the same questions under answers: Manage node groups through the API.

What does Observe produce?

It works from the metrics Hetzner already records, the CPU of each server in the node group and the load balancer’s requests per second and open connections, and from the load balancer’s live target health, which Hetscale reads every minute.

• The day-0 report. Hetscale reads the last 30 days and replays them under the group’s policy. The report shows how many times more capacity was needed, the server range at the busiest point, the extra cost as a range, a confidence label with its reasons, the signals it used and those it cannot see, the days with CPU pinned, the stock of the seed’s server type in the zone (with a sentence when it was available less than 90% of the 30 days), and the recommended policy, Balanced. While it is prepared, the group page shows how much of the 30 days has been read, and a mail says when it is ready.
• Fourteen days of “would”. For 14 days from the start, Hetscale goes on minute by minute and records every decision it would have taken, prefixed “would”, on the group’s timeline. Nothing about the group changes.

What happens when the trial ends?

After the 14 days, Hetscale reads nothing more for the group; its report and timeline stay. From 30 days after the trial, and 30 days after each refresh, Refresh report reads the last 30 days once more, without another 14 days of “would”. How long the Read token is kept is on the privacy page, and what each mode may do is on Modes.