Treat an unknown rich application-health signal as actionable, not healthy

Source facts

For rich HTTP/HTTPS health reporting, a successful HTTP status alone is insufficient: the response must supply the documented ApplicationHealthState value. Invalid payloads, unreachable endpoints, timeouts, or non-2xx responses can produce Unknown. That state can trigger enabled instance repairs and prevents rolling upgrades from progressing until health recovers. TCP reporting has no Unknown state. Only one health-monitoring source may be configured for a scale set before using those orchestration services. Microsoft Learn.

Applicability

Investigate rich HTTP/HTTPS probes, not the binary handler’s status-code-only contract. Identify the deployed handler and endpoint before interpreting a status label. Keep a missing or malformed health signal separate from an application that deliberately reports itself unhealthy, even though both can affect orchestration.

DSE recommendation

Test both the response status and application-health payload, and classify Unknown before enabling dependent repair or upgrade actions. Ask the application owner to define which conditions should explicitly report unhealthy. Include a malformed-response test alongside the expected healthy and unhealthy responses. Confirm that a second, competing monitoring source is not left configured during the change.

Verification

In a disposable test instance, compare the endpoint response with the extension’s reported state. Exercise a valid healthy payload, a deliberate unhealthy payload, and an invalid payload while observing the configured orchestration behavior. Record the response and state together. Do not repeatedly replace instances merely to clear Unknown before investigating the probe contract and endpoint reachability.

Official references

Microsoft Learn: Application Health extension for scale sets. Source reviewed September 9, 2026.