Billing impact
How instance counts change your hourly bill: compute is billed at the hour's average instance count, fixed-price lines are not multiplied, and the billing page shows the math.
Hourly, in arrears
Compute is metered per hour, in arrears: each hour is billed after it completes, based on what actually ran during it. If your instance count changed mid-hour (autoscaling kicked in, you stopped the app, or you scaled manually), the hour is billed at the time-weighted average of the instances that were really running. You are never billed for instances that didn't run.
A worked example
Take an app reserving 0.25 vCPU and 512 MB. At the current rate card one instance costs about $0.0041 per hour (roughly $3 a month). During one hour:
| Period | Running instances |
|---|---|
| Minute 0-30 | 1 |
| Minute 30-60 | 3 |
The average for the hour:
(1 × 0.5 h + 3 × 0.5 h) ÷ 1 h = 2.0 instancesSo that hour is billed at the 2.0-instance average:
2.0 × $0.0041 ≈ $0.0082 for the hourThat is exactly double the single-instance hour, even though the app briefly ran at triple scale. The same rule covers every case: an app stopped at minute 30 averages 0.5 and is billed for half an hour, and an app started at minute 55 costs almost nothing for that hour.
What scales with instances, and what doesn't
| Line item | Multiplied by instances? |
|---|---|
| vCPU | Yes |
| Memory | Yes |
| Custom hostnames | No |
| Registry storage | No |
Only the compute lines (vCPU and memory) follow the instance count. Fixed-price items like custom hostnames and registry storage never multiply, no matter how many instances run.
On the usage page
The Billing page in the portal shows the multiplier explicitly: each compute line carries a "× N avg instances" annotation, so an hour billed at the 2.0 average from the example above reads exactly that way. Drill into any hour to see the breakdown, and check the scaling history on the app's page to see why the count changed. Every entry has a reason and a timestamp.
The balance requirement
Because autoscaling can raise your hourly cost, enabling a policy (or raising its maximum) requires your balance to cover 48 hours at the maximum scale, and the portal's cost preview shows the exact number before you save. The full rule and a worked example are on the autoscaling page. Topping up is the usual flow: redeem a voucher, the value lands as balance, the hourly debits draw from it.
Alerts
Per-service alert policies covering metric, threshold, window, and severity, with portal notifications always and email once your address is verified.
Basin
S3-compatible object storage in the live UAE region for backup files, media, static assets, and app data, with current durability boundaries documented.