# Do not read N/A in Service Health impacted resources as an availability verdict

> Resource Health status is absent where its signal is unavailable, and tenant-scope rows omit that status altogether.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-505-do-not-read-n-a-in-service-health-impacted-resources-as-an-availability-verdict/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:23:31+00:00
- Modified: 2026-09-10T02:11:17+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Resource Health status is absent where its signal is unavailable, and tenant-scope rows omit that status altogether.

## Potentially affected

Azure Service Health investigations using the Service issues Impacted Resources tab.

## DSE recommendation

Keep impact classification separate from the availability of a Resource Health signal.

## Article

## Source facts

Service Health’s Impacted Resources tab lists resources that are or might be affected by a service issue. Impact type can be filtered as Confirmed or Potential, separately from Resource Health status.

At subscription scope, a Resource Health status appears only when its signal is available. Other rows show N/A and a plain-text resource name instead of a health link. Tenant-scope rows omit Resource Health status, tenant name and tenant ID, and also show resource names as plain text. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-health/impacted-resources-outage).

## Applicability

Record the issue, selected subscription or tenant scope, filters and affected resource identifiers. Treat missing health detail as an evidence boundary rather than silently converting it into Available or Unavailable.

## DSE recommendation

DSE recommends maintaining separate fields for reported impact type, available platform health and observed application behavior. Ask the workload owner for the relevant functional evidence when a Resource Health signal is unavailable. Preserve the original N/A value so incident reporting does not manufacture a status the platform did not provide.

## Verification

Compare the incident’s impacted-resource rows with the selected scope and filters. For resources with a health link, review that evidence; for others, document the missing signal and obtain the approved workload checks. Reconcile changes in impact classification over the incident timeline without overwriting earlier observations. A plain-text name or missing status should not by itself close an impact investigation.

## Official references

[Microsoft Learn: Impacted Resources from Service issues](https://learn.microsoft.com/en-us/azure/service-health/impacted-resources-outage). Source retrieved September 9, 2026.

## Primary reference

- Name: Impacted Resources from Service issues - Azure Service Health | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/service-health/impacted-resources-outage
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not read N/A in Service Health impacted resources as an availability verdict,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-505-do-not-read-n-a-in-service-health-impacted-resources-as-an-availability-verdict/
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.