{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/", "slug": "dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart", "url": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/" }, "title": "Separate Service Fabric container health reporting from automatic restart", "summary": "Does an unhealthy Docker HEALTHCHECK automatically restart a Service Fabric container?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:27:42+00:00", "modified_at": "2026-09-10T01:23:48+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 250, "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.", "primary_source": { "name": "Create an Azure Service Fabric container application - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-containers", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

Applicability

\n

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

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

Microsoft Learn. Source retrieved September 9, 2026.

", "content_text": "Source facts\nService 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.\nApplicability\nThe cluster-wide EnableDockerHealthCheckIntegration setting disables this integration when set to false. Microsoft Learn.\nUse 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.\nDSE recommendation\nDSE 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.\nVerification\nOn 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.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nService 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).\n\n## Applicability\n\nThe 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).\n\nUse 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nOn 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.\n\n## Official references\n\n[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-containers). Source retrieved September 9, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/", "url": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Separate Service Fabric container health reporting from automatic restart", "item": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/", "url": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/", "headline": "Separate Service Fabric container health reporting from automatic restart", "description": "Does an unhealthy Docker HEALTHCHECK automatically restart a Service Fabric container?", "abstract": "Does an unhealthy Docker HEALTHCHECK automatically restart a Service Fabric container?", "articleBody": "Source facts\nService 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.\nApplicability\nThe cluster-wide EnableDockerHealthCheckIntegration setting disables this integration when set to false. Microsoft Learn.\nUse 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.\nDSE recommendation\nDSE 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.\nVerification\nOn 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.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "datePublished": "2026-09-10T00:27:42+00:00", "dateModified": "2026-09-10T01:23:48+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-254-separate-service-fabric-container-health-reporting-from-automatic-restart/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Separate Service Fabric container health reporting from automatic restart" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 250, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Create an Azure Service Fabric container application - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-containers" } } ] } }