Check protection and repair service state before expecting an unhealthy instance to recover

Source facts

Automatic repairs skip instances protected from either scale-in or scale-set actions. After a state-changing operation completes, the instance’s grace period delays repair. Repeatedly unhealthy replacements can cause the platform to suspend repairs as a safety measure. The live serviceState distinguishes Running, Suspended, and Not Running. Provisioning failures are outside automatic repairs’ supported recovery scope; instances must first initialize successfully. Microsoft Learn.

Applicability

Investigate a scale set with a configured, valid application health endpoint and an enabled repair policy. Confirm that it is not a Service Fabric scale set, which the source excludes. Identify whether the instance ever initialized successfully before interpreting its unhealthy state as an automatic-repair candidate.

DSE recommendation

Inspect instance protection, grace timing, and the repair service’s live state before changing the repair policy. Ask the workload owner why protection exists and what must be preserved before removing it. For a suspended service, investigate the common reason replacement instances remain unhealthy before resuming. Keep an enabled model property separate from evidence that repair orchestration is currently running.

Verification

Compare instance-view health and repair service state with the configuration and recent state-change timeline. Rehearse the intended recovery on a disposable instance only after the owner approves its repair action and data consequences. Observe whether the replacement or repaired instance becomes genuinely healthy. Retain any repeated failure as unresolved evidence rather than continually resuming repairs against an unchanged underlying problem.

Official references

Microsoft Learn: Automatic instance repairs for scale sets. Source reviewed September 9, 2026.