Autoscaling and alerts
Scale an app automatically between a minimum and maximum number of instances, and get told the moment a service is struggling, both in the portal and by email.
Two tools, one goal
Your app should survive a traffic spike without you watching a dashboard at 3 a.m. You should hear about trouble before your visitors do. Two features cover that:
- Autoscaling adjusts the number of running instances of an app between a minimum and a maximum you choose, based on its average CPU and memory load. More traffic, more instances; quiet again, back down.
- Alerts watch a metric you pick (CPU, memory, response latency, or restarts) and notify you in the portal (and by email, once your address is verified) when it crosses a threshold you set.
Nothing scales that you didn't configure, and nothing fires that you didn't ask for. Both are configured per service, from the service's page in the portal or via the API.
Use autoscaling when your load varies: a shop before holidays, an API with daytime peaks. Use alerts everywhere: they cost nothing, work for apps and managed databases, and are the difference between "the platform told me" and "a customer told me".
Autoscaling
Min/max instances, CPU and memory targets, the balance requirement, and what stop does to a policy.
Alerts
Policy fields, what each metric really measures, the firing lifecycle, and email verification.
Billing impact
How instance counts change your hourly bill, with a worked example.
API reference
Every autoscaling and alert endpoint, with request and response shapes.
Vouchers and balance
Redeem the currently available SYP voucher, track USD credit in your chosen display currency, and understand the live payment boundary.
Autoscaling
Scale an app automatically between a minimum and maximum instance count based on CPU and memory load, with clear rules for cost, balance, and databases.