# Separate Service Fabric container health reporting from automatic restart

> Does an unhealthy Docker HEALTHCHECK automatically restart a Service Fabric container?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:27:42+00:00
- Modified: 2026-09-10T01:23:48+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

Does an unhealthy Docker HEALTHCHECK automatically restart a Service Fabric container?

## Potentially affected

Windows Service Fabric container services using the documented Docker HEALTHCHECK integration.

## DSE recommendation

DSE recommends approving health reporting, severity and restart behavior as separate settings.

## Article

## 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](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-containers).

## Applicability

The cluster-wide EnableDockerHealthCheckIntegration setting disables this integration when set to false. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-containers).

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](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-containers). Source retrieved September 9, 2026.

## Primary reference

- Name: Create an Azure Service Fabric container application - Azure Service Fabric | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-containers
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Separate Service Fabric container health reporting from automatic restart,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.