Skip to main content

Troubleshoot Auto Scaling

Use this page to resolve the most common problems with scale groups. Each section starts from a symptom and links to the relevant guide.

The group is not scaling up​

When the elastic policy never adds nodes:

  • The threshold is never crossed. Compare the Monitoring graph against your scale-up threshold on the Scale Group Details tab. Scaling is evaluated on the average metric across the group, so a single busy node may not move the average enough.
  • The watch period is too long. The metric must stay over the threshold for every period in the watch window (Watch Period × Period Duration). Shorten the watch period or period duration if spikes are brief.
  • You are at maximum nodes. The Scaler never exceeds the maximum. Raise the maximum (up to 50) on the Scale Group Details tab.
  • A cooldown is in effect. No scaling happens during the cooldown after a previous action (default 150 seconds). Check the Audit Logs.

The group is not scaling down​

  • The scale-down threshold is too low, or it is more than half the scale-up value (the portal requires the scale-down value to be below half the scale-up value). Review both thresholds.
  • You are at minimum nodes. The Scaler never drops below the minimum. If you raised the desired count via Resize Service and chose Also update minimum desired nodes, the minimum is now higher — lower it to allow scale-down.

A custom policy is not triggering​

  • No value is being published. A custom attribute defaults to 0 until your script writes to it. Confirm your script and cron job are running on the node, and inspect the attribute with onegate vm show VMID --json.
  • The attribute is not on the image. The custom attribute must be configured on the saved image used to create the group, so every node publishes it. See Custom Scaling Policies.
  • Name mismatch. The policy parameter name in the portal must exactly match the attribute name your script writes.

Status is stuck on Creating, Scaling, Starting, or Stopping​

These are transitional states. Wait for the group to settle, then refresh. While a group is transitioning, most tabs and actions are hidden or disabled by design — see Action Availability. If a group stays in a transitional state far longer than expected, contact support.

An action is disabled​

The Actions menu enables each action only for valid statuses and permissions:

  • Resize Service needs Running/Failed status, the group not Scaling, and update permission.
  • Start needs Stopped status; Stop needs Running status; neither is available while Starting or Stopping.
  • Delete needs Running/Stopped/Failed status, the group not Scaling/Starting/Stopping, and delete permission.

See Scale Group Actions for the full table.

Cannot delete the saved image​

A saved image cannot be deleted while a scale group is using it. Delete the scale group first, then delete the image. See Scale Group Actions.

Stopped group still shows charges​

Stopping a group pauses scale-group billing by setting desired nodes to zero. Attached resources such as a VPC, public IP, or load balancer bill independently. To stop all charges, delete the group and detach or release the attached resources.

New nodes do not start my application​

Group nodes boot from the saved image. If the application does not come up automatically, the image was not configured to launch it at startup. Reconfigure a node so the app starts on boot (for example via a systemd service or startup script), save a new image, and create the group from that image.

Still stuck?​

If a scale group remains in an unexpected state or an action keeps failing, gather the scale group name, location, and recent Audit Logs / Activity Timeline entries, and contact E2E support.

ResourceUse it for
Manage Scale GroupsTabs, statuses, and the management surface.
Scale Group ActionsAction availability and behavior.
Custom Scaling PoliciesFix custom-metric publishing.
MonitoringCompare utilization against thresholds.
Last updated on June 9, 2026.