What an always-on VM actually costs: a real bill, line by line

We sent a usage and billing report to a customer this week, and it contained the cleanest cost lesson we have seen on our own platform. The customer runs two small production apps with us. Over sixteen days the platform metered their total consumption at 1,305 credits. Of that, 1,096 credits, about 84%, went to a single line: compute hours on a virtual machine that never slept.

This post is that bill, line by line, and the alternative that exists for exactly this shape of spending.

The bill

The customer runs two small production apps with us. Here is the full metered consumption for the window, rated against the published price book:

Compute is the story. Not because the workload was heavy, but because the meter never stopped. The VM averaged under one vCPU of actual work. It simply ran for every one of the 384 hours in the window, and per-hour billing charges every one of them.

The math of always-on

Always-on billing has a fixed exchange rate with wall-clock time. A machine that never turns off accrues 730 metered hours in a 31-day month, one for each hour whether it served a million requests or zero.

At our published rates, $0.036 per vCPU-hour and $0.004 per GB-hour of memory, the always-on baseline looks like this:

That is the cost of existence, before the machine does any useful work. It is also why the customer’s compute line dwarfed everything else. Their database stored 4 megabytes. Their object storage held about half a gigabyte. Their whole non-compute bill was about 210 credits. The compute line was five times that, and most of those hours contained no traffic at all.

This is not a scalix-specific trap, and it is not stupidity on anyone’s part. Provisioning a machine is the default reflex of two decades of cloud habits: pick a size, boot it, deploy. The bill is the only place where the habit is visible, and by the time it is visible the machine has been running for weeks.

Scale-to-zero: bill while serving, not while existing

Scale-to-zero inverts that exchange. Compute is metered while it serves, not while it exists. When traffic stops, the instance parks. When the next request arrives, it wakes, serves, and parks again after the idle timeout. Between requests the cost is exactly zero.

On Scalix this exists in three places:

• Functions are billed per invocation and scale to zero between calls. Nothing runs, nothing bills, until a request arrives.
• Run services autoscale. Set the minimum instance count to zero and the service parks when idle, then wakes on request. Our standing demo service runs with a 15-second scale-down window.
• ScalixNova shared Postgres suspends to zero when the database is unused, which is why a database this customer barely queried cost almost nothing.

And for the workloads that genuinely need their own machine, a persistent VM can be stopped and started on a schedule, which is the half-step: pay for twelve hours instead of twenty-four.

The honest latency numbers

Scale-to-zero trades money for a wake. Here is what that trade measured on our production hardware, from the internal bench we ran in July on the snapshot-resume pipeline:

• A parked service woke to serving TCP in roughly 200 milliseconds (measured across 47 consecutive wakes, zero fallbacks).
• A complete first request, end to end through the TLS edge, measured p50 about 600 milliseconds and p99 about 1.2 seconds. The wake itself fits inside that budget; the rest is routing and connection setup.

Those are bench numbers, not a marketing target, and we are publishing them because they are the honest shape of the tradeoff. For an API, a dashboard, a cron-adjacent job, or an internal tool, six-tenths of a second on the first request after idle is imperceptible. For a sub-ten-millisecond p99 path, it is not, and you should keep that workload warm. We would rather hand you the numbers than a slogan.

When always-on is still right

Scale-to-zero is not a moral position, it is a utilization decision. Keep an always-on machine when:

• traffic is genuinely steady around the clock,
• you hold persistent connections such as WebSockets or long-lived streams,
• the workload is stateful in memory and restart cost is real,
• or latency budgets are tight enough that a wake is unacceptable.

The audit that decides it takes one screen: compare billed compute hours against request volume. In this customer’s case, the meter recorded per-minute rows for 384 hours, and the request lines were nearly flat. Hours without requests are the part of the bill you are renting for nothing.

What we told them

The report they received ends with an action list, and it is the same list we would give anyone: move the always-on service to Run with a minimum of zero instances, or stop the VM outside working hours if it must stay a VM; narrow the database queries and cache repeated reads to cut egress; and enable build caching so rebuilds stop paying full price. Executed fully, that list removes most of an 84% line.

The one-key economics behind all of this, compute, Postgres, storage, and AI behind one bill that meters what you actually use, are in One key, one bill, and the pattern of an agent operating this whole stack is in deploying AI agents against a real cloud. The cheapest server remains the one that is not running. Now the platform can bill like you believe it.