{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/", "slug": "dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy", "url": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/" }, "title": "Treat an unknown rich application-health signal as actionable, not healthy", "summary": "What does Unknown mean for an HTTP-based rich health probe, and how does orchestration respond?", "format": { "slug": "explainer", "name": "Explainer" }, "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:28:12+00:00", "modified_at": "2026-09-10T01:20:46+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 247, "potentially_affected": "Azure scale-set instances using the Application Health extension's rich HTTP or HTTPS health states.", "dse_recommendation": "Test both the response status and application-health payload, and classify Unknown before enabling dependent repair or upgrade actions.", "primary_source": { "name": "Use Application Health extension 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-health-extension", "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

For rich HTTP/HTTPS health reporting, a successful HTTP status alone is insufficient: the response must supply the documented ApplicationHealthState value. Invalid payloads, unreachable endpoints, timeouts, or non-2xx responses can produce Unknown. That state can trigger enabled instance repairs and prevents rolling upgrades from progressing until health recovers. TCP reporting has no Unknown state. Only one health-monitoring source may be configured for a scale set before using those orchestration services. Microsoft Learn.

\n

Applicability

\n

Investigate rich HTTP/HTTPS probes, not the binary handler’s status-code-only contract. Identify the deployed handler and endpoint before interpreting a status label. Keep a missing or malformed health signal separate from an application that deliberately reports itself unhealthy, even though both can affect orchestration.

\n

DSE recommendation

\n

Test both the response status and application-health payload, and classify Unknown before enabling dependent repair or upgrade actions. Ask the application owner to define which conditions should explicitly report unhealthy. Include a malformed-response test alongside the expected healthy and unhealthy responses. Confirm that a second, competing monitoring source is not left configured during the change.

\n

Verification

\n

In a disposable test instance, compare the endpoint response with the extension’s reported state. Exercise a valid healthy payload, a deliberate unhealthy payload, and an invalid payload while observing the configured orchestration behavior. Record the response and state together. Do not repeatedly replace instances merely to clear Unknown before investigating the probe contract and endpoint reachability.

\n

Official references

\n

Microsoft Learn: Application Health extension for scale sets. Source reviewed September 9, 2026.

", "content_text": "Source facts\nFor rich HTTP/HTTPS health reporting, a successful HTTP status alone is insufficient: the response must supply the documented ApplicationHealthState value. Invalid payloads, unreachable endpoints, timeouts, or non-2xx responses can produce Unknown. That state can trigger enabled instance repairs and prevents rolling upgrades from progressing until health recovers. TCP reporting has no Unknown state. Only one health-monitoring source may be configured for a scale set before using those orchestration services. Microsoft Learn.\nApplicability\nInvestigate rich HTTP/HTTPS probes, not the binary handler’s status-code-only contract. Identify the deployed handler and endpoint before interpreting a status label. Keep a missing or malformed health signal separate from an application that deliberately reports itself unhealthy, even though both can affect orchestration.\nDSE recommendation\nTest both the response status and application-health payload, and classify Unknown before enabling dependent repair or upgrade actions. Ask the application owner to define which conditions should explicitly report unhealthy. Include a malformed-response test alongside the expected healthy and unhealthy responses. Confirm that a second, competing monitoring source is not left configured during the change.\nVerification\nIn a disposable test instance, compare the endpoint response with the extension’s reported state. Exercise a valid healthy payload, a deliberate unhealthy payload, and an invalid payload while observing the configured orchestration behavior. Record the response and state together. Do not repeatedly replace instances merely to clear Unknown before investigating the probe contract and endpoint reachability.\nOfficial references\nMicrosoft Learn: Application Health extension for scale sets. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nFor rich HTTP/HTTPS health reporting, a successful HTTP status alone is insufficient: the response must supply the documented ApplicationHealthState value. Invalid payloads, unreachable endpoints, timeouts, or non-2xx responses can produce Unknown. That state can trigger enabled instance repairs and prevents rolling upgrades from progressing until health recovers. TCP reporting has no Unknown state. Only one health-monitoring source may be configured for a scale set before using those orchestration services. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension).\n\n## Applicability\n\nInvestigate rich HTTP/HTTPS probes, not the binary handler’s status-code-only contract. Identify the deployed handler and endpoint before interpreting a status label. Keep a missing or malformed health signal separate from an application that deliberately reports itself unhealthy, even though both can affect orchestration.\n\n## DSE recommendation\n\nTest both the response status and application-health payload, and classify Unknown before enabling dependent repair or upgrade actions. Ask the application owner to define which conditions should explicitly report unhealthy. Include a malformed-response test alongside the expected healthy and unhealthy responses. Confirm that a second, competing monitoring source is not left configured during the change.\n\n## Verification\n\nIn a disposable test instance, compare the endpoint response with the extension’s reported state. Exercise a valid healthy payload, a deliberate unhealthy payload, and an invalid payload while observing the configured orchestration behavior. Record the response and state together. Do not repeatedly replace instances merely to clear Unknown before investigating the probe contract and endpoint reachability.\n\n## Official references\n\n[Microsoft Learn: Application Health extension for scale sets](https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension). 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-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/", "url": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Treat an unknown rich application-health signal as actionable, not healthy", "item": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/", "url": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/", "headline": "Treat an unknown rich application-health signal as actionable, not healthy", "description": "What does Unknown mean for an HTTP-based rich health probe, and how does orchestration respond?", "abstract": "What does Unknown mean for an HTTP-based rich health probe, and how does orchestration respond?", "articleBody": "Source facts\nFor rich HTTP/HTTPS health reporting, a successful HTTP status alone is insufficient: the response must supply the documented ApplicationHealthState value. Invalid payloads, unreachable endpoints, timeouts, or non-2xx responses can produce Unknown. That state can trigger enabled instance repairs and prevents rolling upgrades from progressing until health recovers. TCP reporting has no Unknown state. Only one health-monitoring source may be configured for a scale set before using those orchestration services. Microsoft Learn.\nApplicability\nInvestigate rich HTTP/HTTPS probes, not the binary handler’s status-code-only contract. Identify the deployed handler and endpoint before interpreting a status label. Keep a missing or malformed health signal separate from an application that deliberately reports itself unhealthy, even though both can affect orchestration.\nDSE recommendation\nTest both the response status and application-health payload, and classify Unknown before enabling dependent repair or upgrade actions. Ask the application owner to define which conditions should explicitly report unhealthy. Include a malformed-response test alongside the expected healthy and unhealthy responses. Confirm that a second, competing monitoring source is not left configured during the change.\nVerification\nIn a disposable test instance, compare the endpoint response with the extension’s reported state. Exercise a valid healthy payload, a deliberate unhealthy payload, and an invalid payload while observing the configured orchestration behavior. Record the response and state together. Do not repeatedly replace instances merely to clear Unknown before investigating the probe contract and endpoint reachability.\nOfficial references\nMicrosoft Learn: Application Health extension for scale sets. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:28:12+00:00", "dateModified": "2026-09-10T01:20:46+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/" }, "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-224-treat-an-unknown-rich-application-health-signal-as-actionable-not-healthy/#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": "Treat an unknown rich application-health signal as actionable, not healthy" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Explainer", "Information priority" ], "genre": "Explainer", "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": 247, "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": "Use Application Health extension 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-health-extension" } } ] } }