Service Health Data - Is it incomplete ?

Question

Service Health Data - Is it incomplete ?

Ashish Javiya 0

When i go to service health data in az portal, it shows tracking id.
when you try to check the data, it may show many subscriptions is impacted, however when you check for impacted resources it shows nothing.
we tried to fetch the tracking id > then convert it to > RecommendationTypeId > fetch resources.

it still does not have resources.

so how is the data generated or shown for subscription?

Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-05-04T18:51:50.8866667+00:00

Hello Ashish Javiya, thank you for posting your query on Microsoft Q&A platform.

We are looking into your issue and will keep you posted updates. Thanks
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-05-04T19:35:13.39+00:00
Hello Ashish Javiya, You are observing the following behavior in Azure Service Health. A Service Health event (Tracking ID) shows that: multiple subscriptions are impacted. Service Health event that lists impacted subscriptions but no individual “Impacted resources.” That’s actually expected in many cases Service Health at the subscription level is an aggregate view, and not all incidents include per-resource metadata.

How Service Health data is generated: Service Health publishes service-level events (incidents, advisories, planned maintenance) and determines impacted subscriptions based on service and region scope. For broad outages or maintenance (for example, regional service disruption), Azure may not enumerate individual resources. In such cases, the “Impacted resources” section remains empty because no resource-level mapping is available.

Impacted Resources from Service issues - Azure Service Health | Microsoft Learn

Why RecommendationTypeId conversion won’t surface resources: RecommendationTypeId belongs to Azure Advisor, which is a separate recommendation system. Service Health events are identified using trackingId/correlationId, and there is no direct mapping between Service Health and Advisor recommendation IDs.

Azure Service Health notifications data overview - Azure Service Health | Microsoft Learn

Getting resource-level information: For resource-specific status, use Resource Health (portal or API), which shows the health state (Available, Degraded, Unavailable) of individual resources. Impacted Resources from Service issues - Azure Service Health | Microsoft Learn

Note: Resource Health reflects resource telemetry and may not always directly correlate to a Service Health event.

Identify whether the trackingId corresponds to a broad service incident (ServiceIssue or PlannedMaintenance). These events often do not include resource lists.

Use the Service Health REST API to confirm whether impacted resources are available for the event.

If resource-level impact is needed, enumerate resources in the affected region/service (via Resource Graph/ARM) and correlate with Resource Health data for the same timeframe.

Hope this helps, please feel free to reach out if you have any further questions. Thanks
Ashish Javiya 0 Reputation points

2026-05-05T08:15:35.08+00:00
@Bharath Y P Thank you for the detailed explanation and for clarifying the behavior of Azure Service Health events.

I understand that for broad service incidents or advisories, especially those scoped at the subscription or regional level, the “Impacted Resources” section may remain empty due to the absence of resource-level mapping. I also note that resource-level visibility is primarily available through Resource Health, and that RecommendationTypeId from Azure Advisor is not applicable in this context.

However, I would like to kindly confirm understanding that we got from MS logged Case -

For Service Health events categorized as ServiceIssue or PlannedMaintenance, is it always expected that impacted resources may not be available?

Can you please confirm that impacted resource details are only retrievable for Health Advisories specifically related to retirement events?

In cases where no impacted resources are provided, is using Resource Health (or correlating via Resource Graph and ARM) the recommended and only approach for identifying potentially affected resources?

Your confirmation will help ensure we are aligning correctly with the expected design and using the appropriate methods for impact analysis.

Thank you for your support.
Suchitra Suregaunkar 13,785 Reputation points Microsoft External Staff Moderator

2026-05-05T11:13:48.54+00:00
Hello Ashish Javiya,

Thank you for responding back. Please have a look into the information shared for your follow up queries.

For Service Health events categorized as ServiceIssue or PlannedMaintenance, is it always expected that impacted resources may not be available?

This case is not always but it is expected in many cases.

The Impacted Resources tab only shows resources when Azure has resource-level signals available. If those signals are not present, resources won’t be listed even though subscriptions are impacted.

Resource details are conditional (not guaranteed)

Broad incidents (service/region level) may not include resource mapping

Can you please confirm that impacted resource details are only retrievable for Health Advisories specifically related to retirement events?

No, this is not correct. Impacted resources can be shown for Service Issues (outages), can also be shown for Planned Maintenance and for other advisory types.

For Example: Service Issues → resources shown when affected resources can be identified. So, Impacted resources are not limited to retirement/Health Advisory events, they depend on whether Azure can determine impacted resources, not on event type.

When no impacted resources are available, is Resource Health / ARG the recommended approach?

Yes, this is the correct and recommended approach.

Microsoft clearly differentiates:

Service Health → service-level / subscription-level view

Resource Health → resource-level diagnosis and status [learn.microsoft.com]

Resource Health is specifically designed to:

Show actual impact on individual resources

Provide availability status and root cause insights.

Therefore, when Service Health does not provide a resource list:

Use Resource Health for per-resource validation

Optionally use Azure Resource Graph to correlate events and resources.

Thanks,

Suchitra.
Suchitra Suregaunkar 13,785 Reputation points Microsoft External Staff Moderator

2026-05-05T11:14:25.5666667+00:00

Hello Ashish Javiya,

Could you please let us know if the comment above resolved your issue? If you need any further assistance, feel free to reach out, we're always here to support you.

If you found the comment helpful, please consider clicking "Upvote it."

Thanks,

Suchitra.
Ashish Javiya 0 Reputation points

2026-05-05T11:26:56.3333333+00:00

@**Suchitra Suregaunkar is there way we can connect.

basically, what i see in UI on service health was told to be seen using API/Programmatically

UI :**

**Using API : (as recommended by MS)

**
Suchitra Suregaunkar 13,785 Reputation points Microsoft External Staff Moderator

2026-05-05T11:34:01.9666667+00:00

Hello Ashish Javiya,

Please share me the details asked via Private Message.
Ashish Javiya 0 Reputation points

2026-05-05T11:40:41.9366667+00:00

@Suchitra Suregaunkar shared the details requested.
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-05-05T22:50:42.9866667+00:00
We understand that Service Health data is available via APIs, but when comparing portal data with API responses, inconsistencies appear. Some tracking IDs visible in the Service Health interface are missing from API results, and conversely, some API-returned data does not appear in the portal.

The process involves retrieving a tracking ID from API or Service Health, then using that ID in additional queries (such as Azure Resource Graph queries) to fetch resource-level impact details. Without consistent tracking IDs across systems, this correlation breaks down, preventing accurate reporting.

The portal dynamically queries your live Azure inventory to show impacted resources. The API does not do this it only returns what is statically stored in the retirement event record.

The Service Health portal dynamically queries live Azure subscription inventory to display impacted resources. The API does not replicate this behavior it only returns statically stored fields in the retirement event record. This Impact Platform-level retirements return subscription and region via API but zero resource names breaking the entire downstream reporting chain.

Some Tracking IDs visible in the Service Health portal UI are absent from API responses, and vice versa. Without a consistent Tracking ID, no downstream ARG query can fetch resource-level details. The correlation workflow - Tracking ID > ARG query > Impacted Resources - breaks at the first step for missing IDs.

Microsoft publishes two distinct retirement advisory types. Resource-level retirements store impacted resource data in the event record. Platform/service-level retirements do not - they only store subscription and region scope. A single API query returns inconsistent field completeness depending on the retirement type, with no clear flag to distinguish them programmatically.

The pipeline initially relied solely on the Service Health API as the source of truth for retirement data. Advisory API (which does return full resource mapping) was not integrated for the retirement use case. A complete, working data source was available but not yet wired into the retirement reporting pipeline.

The hybrid enrichment pipeline resolves the gap by combining three sources Advisory API, ARG event data, and ARG inventory cross-reference into a single canonical dataset with source traceability. This means:

Resource-level retirements are fully enriched with resource names via Advisory API

Platform-level retirements are enriched through ARG inventory inference, replicating what the portal does dynamically

Every record carries a confidence score so the dashboard is transparent about data quality.

Azure Service Health APIs and the portal are not fully consistent, especially for tracking IDs and impacted resource data. This inconsistency breaks correlation workflows, making API-only pipelines unreliable.

Hope this helps! please let us know if you have any questions, thanks