Separate Service Fabric container health reporting from automatic restart

Source facts

Service Fabric’s documented Docker health integration includes container health in system reporting by default, while automatic restart and treating an unhealthy result as an error both default to false. Enabling RestartContainerOnUnhealthyDockerHealthStatus restarts a repeatedly unhealthy container, possibly on another node. The image must contain a HEALTHCHECK instruction that invokes the actual check. Microsoft Learn.

Applicability

The cluster-wide EnableDockerHealthCheckIntegration setting disables this integration when set to false. Microsoft Learn.

Use this review for an existing compatible Windows container deployment, not as a current deployment recipe for the tutorial’s older sample images. Identify what the check measures before deciding whether its failure should be reported, escalated or used to restart the workload.

DSE recommendation

DSE recommends approving health reporting, severity and restart behavior as separate settings. Have the application owner explain whether a restart is useful for the detected condition and what work must be preserved. Do not assume a warning implies a restart policy, and do not enable repeated restarts merely to make a health display recover. Keep a persistent diagnostic signal available for investigation.

Verification

On a test deployment, inspect the cluster integration setting and effective HealthConfig and deliberately trigger the defined check failure. Observe the health report and container lifecycle independently, then restore the healthy condition and repeat as needed to confirm the approved behavior. Record the check definition, configuration and observed restart decision together. Verify the application’s useful operation after recovery rather than accepting a newly started container alone.

Official references

Microsoft Learn. Source retrieved September 9, 2026.