What is scale-to-zero and how does it change cloud cost?

What is scale-to-zero?

Scale-to-zero flips the traditional cloud billing model: you pay only for the time your code is actually processing requests, not for the time a virtual machine simply exists. When traffic stops, the platform pauses the instance and your compute meter drops to zero. The next incoming request triggers a wake-up, the instance serves the request, and then it returns to a paused state after the idle timeout expires. This means idle hours generate no cost, while active hours are metered precisely to the work done.

Our internal billing data shows the impact of always-on compute. In a recent 16-day window, a customer’s total platform consumption was 1,305 credits, of which 1,096 credits,about 84 %, came from a single line: vCPU-hours on a virtual machine that never slept. The VM averaged under one vCPU of real work but ran for every hour in the period, so the per-hour meter charged for idle time as if it were doing useful work.

The math of always-on

Always-on billing has a fixed exchange 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 work. In the example above, the customer’s database stored only a few megabytes and object storage held less than a gigabyte, so the non-compute portion of the bill was roughly 210 credits. The compute line was five times larger, and most of those hours contained no traffic at all. This is not a Scalix-specific trap; it is the outcome of two decades of cloud habits where the default is to pick a size, boot it, and leave it running.

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

With scale-to-zero the meter only runs while the instance is actively serving. When the request stream stops, the platform parks the instance and the compute cost drops to exactly zero. When the next request arrives, the instance wakes, serves the request, and then parks again after the idle timeout. Between requests you pay nothing.

On Scalix this model appears in three places:

• Functions - billed per invocation and scale to zero between calls. Nothing runs, nothing bills, until a request arrives.
• Run services - autoscale based on traffic; setting the minimum instance count to zero lets a service park when idle and wake on request.
• ScalixNova shared Postgres - suspends to zero when unused, so you only pay for storage and the brief compute bursts needed to serve queries.

Wake latency

The trade-off is latency on the first request after an idle period. Our production benchmarks measured a parked service waking to serve TCP in roughly 200 ms median, and a full first request through the TLS edge taking about 600 ms median. For APIs, dashboards, and internal tools this delay is imperceptible. For sub-ten-millisecond p99 paths you would keep the workload warm with an always-on instance or a higher minimum count.

When to keep an always-on VM

Keep an always-on machine when:

• Traffic is steady around the clock.
• You rely on persistent connections such as WebSockets or long-running database sessions.
• The workload is stateful and latency-sensitive to the point that even a few hundred milliseconds of wake-up time hurts your SLO.

A simple audit is to compare your billed compute hours to your request volume. Hours without requests are the portion you are renting for nothing; those are the hours scale-to-zero would eliminate.

Which Scalix products support scale-to-zero?

• Functions - per-invocation billing, automatic scale-to-zero.
• Run services - autoscale with min-instance-count set to zero.
• ScalixNova Postgres - suspends to zero when unused, waking on the first query.

If you want to see scale-to-zero in action, try deploying a function from our docs or start a Run service with a zero minimum. The free tier provides a starting line for experimentation, and you can move to a paid plan as your usage grows.

Read the functions quickstart to deploy your first scale-to-zero endpoint today.