Autoscaling

Autoscaling moves a resource up and down the plan ladder on its own, based on CPU usage, between a floor and a ceiling that you choose. You are never scaled onto a plan you did not authorise.

It is available on web services, tools (n8n), databases, and WordPress sites. The panel and the behaviour are identical everywhere — open the resource from the dashboard and select the Autoscaling tab.

How it works

You set four things:

Scale up at (%) — when CPU usage stays above this, the resource moves up one plan. Default 80.
Scale down at (%) — when CPU usage stays below this, it moves back down. Default 20.
Minimum plan — the floor. Autoscaling will never go below it, so a quiet week cannot drop you onto something too small to serve traffic.
Maximum plan — the ceiling. This is your cost limit. Autoscaling will never move past it, whatever the load does.

Turn on Automatically adjust capacity to activate the rule, then choose Save autoscaling. The panel shows the current capacity above the fields so you can see where the resource sits right now.

Choosing thresholds

The gap between the two thresholds matters more than either number.

A narrow gap — scaling up at 70% and down at 60% — makes the resource change plans often, and each change is a restart. A wide gap absorbs normal variation and only reacts to a real shift in load. The defaults of 20 and 80 are a reasonable starting point for most workloads.

If a service is bursty by nature, raise the scale-up threshold rather than lowering it. Scaling up on a thirty-second spike costs a restart and buys nothing, because the spike is over before the new plan is serving.

Rules the form enforces

A rule is rejected if:

either threshold falls outside 0–100
the scale-down threshold is not strictly below the scale-up threshold
the minimum plan sits above the maximum plan in the ladder

The last one catches a common mistake: the plans are ordered, so “minimum BasicPlus, maximum Basic” is not a valid range and the form will say so rather than saving something that cannot act.

Activity history

Everything autoscaling does is recorded under Recent activity, five entries per page:

Plan upgraded / Plan downgraded — a scale action completed, showing the plan it moved from and to.
Upgrade limit reached — load called for more capacity but the resource is already on the maximum plan. If you see this repeatedly, raise the ceiling.
Downgrade limit reached — the same at the floor. Usually harmless, and a sign the minimum plan is larger than the workload needs.
OOM recovery — the resource ran out of memory and autoscaling moved it up to recover it.
Rollout — the plan change was applied to the running resource.

Routine evaluations that changed nothing are not listed, so the history stays readable — if something is in it, something happened.

Insufficient balance

Autoscaling spends money, so it stops when the account cannot pay for it. When that happens the rule disables itself and the panel shows:

Disabled due to insufficient balance. Fund the team owner account, then re-enable this rule.

Two things worth knowing. The balance that matters is the team owner’s, not necessarily the account that created the resource — on a team these can differ. And the rule is not deleted, only switched off, so funding the account and toggling it back on restores your existing thresholds and plan bounds.

What it does not do

Autoscaling changes the plan a resource runs on. It does not add replicas or run several copies behind a load balancer. A resource that is CPU-bound in a way one plan cannot satisfy needs the workload split, not a larger plan.

It also reacts to sustained usage rather than instantly. A traffic spike that arrives and finishes inside a minute is served by the plan you were already on. Set the minimum plan to cover your normal floor and treat autoscaling as protection against sustained load, not as a substitute for capacity planning.