{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/", "slug": "dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance", "url": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/" }, "title": "Check protection and repair service state before expecting an unhealthy instance to recover", "summary": "Why can a scale-set instance remain unhealthy even though automatic repairs are enabled?", "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:29:36+00:00", "modified_at": "2026-09-10T00:52:39+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 245, "potentially_affected": "Azure scale sets with automatic repairs and application health monitoring, excluding unsupported Service Fabric scale sets.", "dse_recommendation": "Inspect instance protection, grace timing, and the repair service's live state before changing the repair policy.", "primary_source": { "name": "Automatic instance repairs with Azure Virtual Machine Scale Sets - Azure Virtual Machine Scale Sets | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-instance-repairs", "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

Automatic repairs skip instances protected from either scale-in or scale-set actions. After a state-changing operation completes, the instance’s grace period delays repair. Repeatedly unhealthy replacements can cause the platform to suspend repairs as a safety measure. The live serviceState distinguishes Running, Suspended, and Not Running. Provisioning failures are outside automatic repairs’ supported recovery scope; instances must first initialize successfully. Microsoft Learn.

\n

Applicability

\n

Investigate a scale set with a configured, valid application health endpoint and an enabled repair policy. Confirm that it is not a Service Fabric scale set, which the source excludes. Identify whether the instance ever initialized successfully before interpreting its unhealthy state as an automatic-repair candidate.

\n

DSE recommendation

\n

Inspect instance protection, grace timing, and the repair service’s live state before changing the repair policy. Ask the workload owner why protection exists and what must be preserved before removing it. For a suspended service, investigate the common reason replacement instances remain unhealthy before resuming. Keep an enabled model property separate from evidence that repair orchestration is currently running.

\n

Verification

\n

Compare instance-view health and repair service state with the configuration and recent state-change timeline. Rehearse the intended recovery on a disposable instance only after the owner approves its repair action and data consequences. Observe whether the replacement or repaired instance becomes genuinely healthy. Retain any repeated failure as unresolved evidence rather than continually resuming repairs against an unchanged underlying problem.

\n

Official references

\n

Microsoft Learn: Automatic instance repairs for scale sets. Source reviewed September 9, 2026.

", "content_text": "Source facts\nAutomatic repairs skip instances protected from either scale-in or scale-set actions. After a state-changing operation completes, the instance’s grace period delays repair. Repeatedly unhealthy replacements can cause the platform to suspend repairs as a safety measure. The live serviceState distinguishes Running, Suspended, and Not Running. Provisioning failures are outside automatic repairs’ supported recovery scope; instances must first initialize successfully. Microsoft Learn.\nApplicability\nInvestigate a scale set with a configured, valid application health endpoint and an enabled repair policy. Confirm that it is not a Service Fabric scale set, which the source excludes. Identify whether the instance ever initialized successfully before interpreting its unhealthy state as an automatic-repair candidate.\nDSE recommendation\nInspect instance protection, grace timing, and the repair service’s live state before changing the repair policy. Ask the workload owner why protection exists and what must be preserved before removing it. For a suspended service, investigate the common reason replacement instances remain unhealthy before resuming. Keep an enabled model property separate from evidence that repair orchestration is currently running.\nVerification\nCompare instance-view health and repair service state with the configuration and recent state-change timeline. Rehearse the intended recovery on a disposable instance only after the owner approves its repair action and data consequences. Observe whether the replacement or repaired instance becomes genuinely healthy. Retain any repeated failure as unresolved evidence rather than continually resuming repairs against an unchanged underlying problem.\nOfficial references\nMicrosoft Learn: Automatic instance repairs for scale sets. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAutomatic repairs skip instances protected from either scale-in or scale-set actions. After a state-changing operation completes, the instance’s grace period delays repair. Repeatedly unhealthy replacements can cause the platform to suspend repairs as a safety measure. The live serviceState distinguishes Running, Suspended, and Not Running. Provisioning failures are outside automatic repairs’ supported recovery scope; instances must first initialize successfully. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-instance-repairs).\n\n## Applicability\n\nInvestigate a scale set with a configured, valid application health endpoint and an enabled repair policy. Confirm that it is not a Service Fabric scale set, which the source excludes. Identify whether the instance ever initialized successfully before interpreting its unhealthy state as an automatic-repair candidate.\n\n## DSE recommendation\n\nInspect instance protection, grace timing, and the repair service’s live state before changing the repair policy. Ask the workload owner why protection exists and what must be preserved before removing it. For a suspended service, investigate the common reason replacement instances remain unhealthy before resuming. Keep an enabled model property separate from evidence that repair orchestration is currently running.\n\n## Verification\n\nCompare instance-view health and repair service state with the configuration and recent state-change timeline. Rehearse the intended recovery on a disposable instance only after the owner approves its repair action and data consequences. Observe whether the replacement or repaired instance becomes genuinely healthy. Retain any repeated failure as unresolved evidence rather than continually resuming repairs against an unchanged underlying problem.\n\n## Official references\n\n[Microsoft Learn: Automatic instance repairs for scale sets](https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-instance-repairs). Source reviewed 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-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/", "url": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Check protection and repair service state before expecting an unhealthy instance to recover", "item": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/", "url": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/", "headline": "Check protection and repair service state before expecting an unhealthy instance to recover", "description": "Why can a scale-set instance remain unhealthy even though automatic repairs are enabled?", "abstract": "Why can a scale-set instance remain unhealthy even though automatic repairs are enabled?", "articleBody": "Source facts\nAutomatic repairs skip instances protected from either scale-in or scale-set actions. After a state-changing operation completes, the instance’s grace period delays repair. Repeatedly unhealthy replacements can cause the platform to suspend repairs as a safety measure. The live serviceState distinguishes Running, Suspended, and Not Running. Provisioning failures are outside automatic repairs’ supported recovery scope; instances must first initialize successfully. Microsoft Learn.\nApplicability\nInvestigate a scale set with a configured, valid application health endpoint and an enabled repair policy. Confirm that it is not a Service Fabric scale set, which the source excludes. Identify whether the instance ever initialized successfully before interpreting its unhealthy state as an automatic-repair candidate.\nDSE recommendation\nInspect instance protection, grace timing, and the repair service’s live state before changing the repair policy. Ask the workload owner why protection exists and what must be preserved before removing it. For a suspended service, investigate the common reason replacement instances remain unhealthy before resuming. Keep an enabled model property separate from evidence that repair orchestration is currently running.\nVerification\nCompare instance-view health and repair service state with the configuration and recent state-change timeline. Rehearse the intended recovery on a disposable instance only after the owner approves its repair action and data consequences. Observe whether the replacement or repaired instance becomes genuinely healthy. Retain any repeated failure as unresolved evidence rather than continually resuming repairs against an unchanged underlying problem.\nOfficial references\nMicrosoft Learn: Automatic instance repairs for scale sets. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:29:36+00:00", "dateModified": "2026-09-10T00:52:39+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/" }, "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-140-check-protection-and-repair-service-state-before-expecting-an-unhealthy-instance/#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": "Check protection and repair service state before expecting an unhealthy instance to recover" }, "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": 245, "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": "Automatic instance repairs with Azure Virtual Machine Scale Sets - Azure Virtual Machine Scale Sets | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-instance-repairs" } } ] } }