|Manuals

Staged Power On/Off Issues

Staged Power On/Off misbehaviors usually have one of three causes: a misconfiguration in the model itself, an interaction with another setting that produces unexpected combined behavior, or a deployment-state issue where the pool has fewer instances than the staging logic expects. This article covers the most common problems and how to diagnose them.

Staged Power On/Off Is Not Visible in the Power Tab

Symptoms: You expand the Power tab in the model editor and the Staged Power On/Off sub-section is not present.

Most likely cause: Allow Pool Mode has not been enabled in the General tab. Without it, the Pool Mode field is hidden entirely and the Staged Power On/Off sub-section does not appear in the Power tab.

Diagnosis and fix:

  1. Open the General tab. Confirm Allow Pool Mode is enabled. If it is disabled, the Pool Mode field is hidden and Staged Power On/Off does not appear in the Power tab.
  2. With Allow Pool Mode enabled, Pool Mode defaults to Breadth First. Confirm the value matches your intended pool behavior, and change it to Depth First if needed.
  3. Save the model after making any change to General before reopening the Power tab.
  4. Back in the Power tab, the Staged Power On/Off sub-section is now visible. Toggle Enable on to start configuring it.

If Allow Pool Mode is enabled and the sub-section still does not appear, the model may be in an unexpected state. Try closing and reopening the model editor, or refreshing the Cloud Manager screen.

Pool Does Not Scale Out Under Load

Symptoms: Users report slow connections during peak demand. The Instances tab shows fewer running VMs than expected, and the count does not rise as users connect.

Most likely causes (in order of likelihood):

  1. Pool has reached Max Instances Count. The staging logic cannot power on more instances than this ceiling allows. Check the General tab for the configured value, and the Instances tab for the current count. If they match, the ceiling is the constraint.
  2. Occupancy Threshold is at or above Max Users per Instance. If the threshold is set equal to or higher than the per-VM session cap, it can never trip — VMs refuse new sessions before reaching the threshold value. This is a configuration error, not a tuning issue, and is fixed by lowering Occupancy Threshold below Max Users per Instance.
  3. Occupancy Threshold is too high relative to actual demand. If sessions are not pushing per-VM session counts above the threshold, no scale-out occurs. With Breadth First, sessions distribute evenly, so the threshold trips only as the pool collectively fills. With Depth First, sessions stack on the active VM until it fills.
  4. Pool has not finished deploying. Newly-deployed instances take 3 to 7 minutes per instance for OCI Compute, longer for some other providers. Until the deployment completes, the staging logic has fewer instances to act on than the configuration suggests.
  5. You are outside a scheduled window in Scheduled mode. In Scheduled mode, the staging logic runs only during defined time windows. Outside those windows the pool stays in whatever state it was in when the window ended, and does not power on again until the next scheduled window begins. If users need pool availability outside the schedule, switch to Both mode, which falls back to On Demand behavior outside the windows.

Diagnosis and fix:

  1. Open the model editor and check Max Instances Count in the General tab. If the pool is at the ceiling, raise it or accept that peak demand will exceed capacity.
  2. In the General tab, check Max Users per Instance, and in the Power tab, check Occupancy Threshold. Confirm Occupancy Threshold is below Max Users per Instance — if not, the threshold can never trip and must be lowered, or Max Users per Instance must be raised.
  3. Open the Power tab and check Occupancy Threshold against your demand pattern. Lower it if scale-out is not triggering early enough — see Tuning Staged Power by Workload Pattern for guidance.
  4. Open the Deployments tab and check for in-progress or failed deployments. Resolve any failures before adjusting staging configuration.
  5. If using Scheduled mode, confirm the current time falls within a defined schedule entry. Add an entry covering the affected period or switch to Both mode if demand falls outside the predictable pattern.

Pool Does Not Scale In When Idle

Symptoms: VMs remain powered on long after user sessions end. Cost is higher than expected.

Most likely causes:

  1. Stop after disconnect is 0. A value of 0 disables the automatic post-disconnect power-off entirely — instances stay running indefinitely after the last session ends. Confirm the field has a positive value (in minutes).
  2. VMs never become empty. Staged Power On/Off only releases VMs with zero active sessions. If users close their browser tabs without logging off, sessions may persist until a server-side timeout and the VM never empties.
  3. Power Off Threshold is too low and a one-VM buffer is being kept. When no non-empty VM is at or below the threshold, Cloud Manager retains one empty VM as a buffer above Initial Start Count. Raising Power Off Threshold (so that an under-utilized VM trips it) releases the buffer.
  4. Power Off Delay is too long. A 30-minute delay means VMs run for half an hour after being marked for release. Combined with Stop after disconnect, total idle time before power-off can be substantial.
  5. Stop after disconnect compounds with Power Off Delay. As described in Staged Power On/Off — Interaction with Related Settings, the two delays add together. Total idle time = Stop after disconnect + Power Off Delay.

Diagnosis and fix:

  1. Identify a specific VM that should have powered off but didn’t. Note when the last user session on that VM ended and how long the VM has been running since.
  2. Confirm Stop after disconnect is greater than 0. If it is 0, the post-disconnect power-off is disabled and the VM will run until another mechanism stops it.
  3. Calculate expected idle time: Stop after disconnect + Power Off Delay. If the VM has been running longer than this sum and the VM is empty, the staging logic should have powered it off — investigate the Power Off Threshold value (is the pool keeping a buffer?) or session cleanup on the VM.
  4. If the VM is empty and above Initial Start Count and the combined delay has elapsed, check whether the model was modified recently. Configuration changes take effect only on the next staging cycle.
  5. For pools that chronically retain a single warm buffer above the baseline, raise Power Off Threshold so that the buffer is released when underused VMs are present.

Pool Power-Cycles Frequently

Symptoms: The same empty VMs power on and off repeatedly in short cycles. Users notice intermittent slowness as VMs come back online to absorb returning demand. Cloud provider logs show high power-state-change activity.

Most likely cause: Power Off Threshold is set high relative to Occupancy Threshold, causing the buffer-release condition to trip frequently as sessions ramp up and down.

Example: With Occupancy Threshold = 3 and Power Off Threshold = 2, sessions dropping briefly to 2 on a non-empty VM release the warm-buffer empty VM (power-off scheduled in Power Off Delay minutes); a new user then arrives, total sessions cross the scale-out trigger, and Cloud Manager powers a fresh VM back on. The cycle repeats.

Diagnosis and fix:

  1. Compare Occupancy Threshold and Power Off Threshold. A wider gap means transient session fluctuations are less likely to both release the buffer and immediately re-trigger scale-out.
  2. Raise Power Off Delay to absorb brief idle periods — a 15-minute delay gives sessions time to return before the pending power-off fires.
  3. Confirm the Pool Mode matches your threshold values. Depth First with a low Occupancy Threshold can cause rapid trip-and-recovery cycles as sessions stack on a single VM.

For chronic oscillation in a pool with steady total demand, Both mode with a small Initial Start Count baseline can stabilize the bottom of the pool, preventing scale-in from going below a useful minimum.

Initial Start Count Has No Effect

Symptoms: In Scheduled or Both mode, the Initial Start Count value is set, but the count of running instances at the start of a scheduled window does not match.

Most likely causes:

  1. The schedule window is not actually starting. Schedule times are entered in the configuring administrator’s time zone and converted to each end user’s time zone at runtime. Confirm the window is active in the time zone of the users experiencing the issue, not just in your own time zone.
  2. The pool has fewer deployed instances than Initial Start Count. The staging logic cannot power on instances that don’t exist. If Initial Start Count = 5 but only 3 instances have been deployed, the pool will power on 3 — not 5.
  3. Instances from the previous cycle are still running and counted toward the baseline. The new window’s Initial Start Count brings the running count up to that number, not in addition to existing running instances.
  4. Mode is set to On Demand. Initial Start Count is unavailable in On Demand mode. If you set the field while in Scheduled or Both mode and then switched to On Demand, the value is ignored.

Diagnosis and fix:

  1. Confirm Mode is Scheduled or Both.
  2. Open the Deployments tab and confirm the deployment is complete. The pool must have at least Initial Start Count instances deployed for the value to take effect.
  3. Check the schedule entry against the current time in the time zone of the affected users.
  4. If a previous schedule window’s instances are still running into the new window (because of a long Stop after disconnect delay), the new baseline is applied as a top-up to that running count.

Verification Checklist

When Staged Power On/Off behavior is confusing, run through this checklist before opening a support ticket:

  • Allow Pool Mode is enabled in General (this is what makes the Pool Mode field visible and Staged Power On/Off available).
  • Pool Mode is set to Breadth First (the default) or Depth First, matching your intended pool behavior.
  • Max Instances Count (in General) is greater than 1 and large enough to accommodate peak demand.
  • Max Users per Instance (in General) is set to the per-VM session capacity your workload actually uses, not the default of 1. Occupancy Threshold is below Max Users per Instance so the threshold can trip before VMs refuse new sessions.
  • The model has been deployed successfully and at least the configured Initial Start Count number of instances exists in the pool.
  • Mode (in Power) is set to the value matching your intended operating model.
  • Staged Power On/Off is enabled (the Enable toggle is on).
  • Threshold values have a meaningful gap between them (Occupancy Threshold > Power Off Threshold + 1).
  • Stop after disconnect is greater than 0 and set to a reasonable value relative to Power Off Delay — remember the two compound, and 0 disables post-disconnect power-off entirely.
  • Schedule entries (in Scheduled or Both modes) cover the time periods you expect them to.
  • Exception Dates do not include the current date.

If all of the above are correct and the pool still behaves unexpectedly, capture the Instances tab state, the Deployments tab state, and the model configuration, and contact support with the captured data.

See Also