Autoscaling

What it does

Autoscaling watches your app's average CPU and memory usage and adjusts the number of running instances between a minimum and a maximum you choose. When load stays above your target, instances are added; when it falls back, instances are removed, gradually, never abruptly. You configure it per app from the Scaling section on the app's page in the portal, or via the API.

Autoscaling applies to apps only. Managed databases run at a fixed instance count in this first release. See the honest note below.

The policy

At least one target (CPU or memory) is required. Targets compare against the average across your running instances, measured against each instance's reserved CPU and memory, the same reservation you chose when creating the app.

Scale-down stabilization

Scaling up is fast; scaling down is deliberately slow. The stabilization window is how long usage must stay below the target before an instance is removed. The default of 300 seconds (5 minutes) prevents flapping: adding and removing instances every minute as load wobbles around the target. Raise it if your traffic comes in bursts; lower it if you want cost to track load tightly.

Stopping the app overrides the policy

Stop always wins. Stopping an app scales it to zero even when an autoscaling policy is active. The policy itself is kept: when you start the app again, autoscaling resumes exactly as configured, no reconfiguration needed. The same applies to a billing suspension: a suspended app scales to zero regardless of the policy.

Manual instance editing is locked

While a policy is active, autoscaling owns the instance count. The instance field in the app's edit dialog is disabled with a hint pointing to the scaling policy, and an API request to change it directly is rejected with 409 AUTOSCALING_OWNS_REPLICAS. To set a fixed count again, disable the policy first: your app then keeps running at the last instance count autoscaling reached, and the field unlocks.

The project ceiling

Your plan caps the total number of instances a project can run. When you save a policy, its maximum counts against that ceiling together with every other service in the project (a service without a policy counts as its current instance count). If the sum would exceed the ceiling, the save is rejected with 409 QUOTA_EXCEEDED. Lower the maximum here or in another service.

The balance requirement

Scaling out costs money, so enabling a policy, or raising its maximum, requires that your current balance covers at least 48 hours of running at the maximum scale:

required balance = hourly cost at maximum instances × 48 hours

Why 48 hours: it is the platform's grace window. The requirement guarantees that a scale-out you asked for can't immediately drive your balance into debt the moment traffic arrives.

A worked example. An app reserving 0.25 vCPU and 512 MB costs about $0.0041 per hour per instance (roughly $3 a month). With a maximum of 4 instances:

hourly at maximum  = 4 × $0.0041  ≈ $0.0165
required balance   = $0.0165 × 48 ≈ $0.79

If your balance is below the requirement, the save is rejected with 422 INSUFFICIENT_BALANCE_FOR_AUTOSCALING and the message tells you the exact amount needed. The cost preview in the portal shows the same number before you save, and the estimated monthly cost at both the minimum and the maximum, so there are no surprises. Redeem a voucher to top up, then save again.

If your balance later runs to zero while the app is scaled out, the normal grace-period suspension applies: the app is suspended and scaled to zero like any other unpaid workload.

Managed databases don't autoscale (yet)

In this first release, autoscaling is for apps only. A request to attach a policy to a managed Postgres, MySQL, or Redis service is rejected with 409 UNSUPPORTED_SERVICE_TYPE. The honest reason: scaling a database's instance count safely requires replication and storage expansion mechanics that aren't ready yet, and we won't ship a toggle that risks your data.

What managed databases do get is the full alerts surface: CPU, memory, storage, and restart policies work for them exactly as for apps, so you still hear about a struggling database the moment it struggles.

Every change is recorded

Every instance-count change is recorded in the scaling history on the app's page (and in Activity), with its reason: automatic scaling, a manual change, start, stop, suspend, or resume. History is kept for 90 days. The same events drive the billing math: what you see scaled is what you pay for.