Distinguish suppressed and limited dependency impact in a health-model preview

Source facts

In the Azure Monitor health-model preview, Suppressed impact prevents a child’s degraded or unhealthy state from influencing its parent. Limited impact instead reduces the propagated severity: a degraded child is treated as healthy, and an unhealthy child as degraded. Dependency aggregation determines how children combine, while the child’s impact setting changes its contribution. The tutorial assumes child entities already have signals determining their health. Microsoft Learn.

Applicability

Use these settings only within an approved preview evaluation. Distinguish a genuinely optional component from one whose failure leaves the service available with reduced capability. Establish the intended parent behavior before choosing either impact mode.

DSE recommendation

Choose impact behavior from the dependency’s actual contribution to the user journey, not from a desire to keep the parent green. Ask the service owner to describe what users lose when that child degrades or fails. Use that explanation to justify suppression or reduced severity, and retain a separate operational responsibility for the child. Review the decision again if fallback behavior or the component’s purpose changes.

Verification

In a controlled model exercise, inspect the child, parent and workload states as the child changes between the relevant health conditions. Compare the observed rollup with the documented service tolerance. Check that the child signal itself is meaningful before evaluating propagation. Preserve both the dependency setting and its business justification so a healthy parent is not later mistaken for proof that every component is healthy.

Official references

Microsoft Learn: Health-model rollup preview. Source reviewed September 9, 2026.