Freeze rolling-upgrade phase and skip decisions before the upgrade starts

Source facts

Rolling-upgrade custom metrics require rich Application Health extension states over HTTP or HTTPS; binary states and TCP are unsupported for this integration. Azure reads the metrics when the upgrade starts, so mid-upgrade changes do not alter that operation. Phases run in numeric order, with every batch in a phase completed before the next; a missing phase places the VM last. A true skip decision excludes an instance. The customMetrics payload must be a JSON string, not a nested object. Microsoft Learn.

Applicability

Use this check when applications emit their own rollout ordering or omission decisions. Confirm a healthy application state before expecting inclusion, as required by the source. Keep these inputs separate from an assumption that every later health response rewrites the active rollout plan.

DSE recommendation

Validate the reported phase and skip decisions before starting a rolling upgrade, and retain that input snapshot with the operation. Have each application owner justify omitted instances and define how their later update will be tracked. Review machines with no phase deliberately instead of letting a missing field silently stand in for the intended order.

Verification

Inspect the reported custom-metrics substatus for representative instances and compare it with the intended phases. Rehearse a small rollout and confirm the observed batch sequence and skipped population. If an owner changes a decision after the operation begins, record the change separately and reassess the rollout rather than claiming the active operation adopted it. Retain remaining outdated instances as explicit follow-up work.

Official references

Microsoft Learn: Rolling-upgrade custom metrics. Source reviewed September 9, 2026.