Check Exchange Online Service Health via Microsoft Graph

Why check Exchange Online service health?

When users report email delays, delivery failures, Outlook connectivity issues, or mailbox access problems, the first triage step is determining whether the root cause is a Microsoft-side service incident or something specific to your tenant. Microsoft 365 exposes real-time service health data through the serviceAnnouncement endpoint in Microsoft Graph, allowing administrators to quickly confirm whether Exchange Online is operating normally.

When to run this recipe

• During active user-reported email incidents, before deeper mailbox-level troubleshooting.
• As part of a scheduled daily or hourly health check for NOC dashboards.
• Before announcing a tenant-side incident to end users — rule out a Microsoft-side outage first.
• When reviewing post-incident timelines and correlating user impact to Microsoft advisories.

The health status returned reflects Microsoft's view of the service for your tenant. Possible values include serviceOperational, investigating, serviceDegradation, serviceInterruption, restoringService, extendedRecovery, serviceRestored, and falsePositive.

What you will have after running this recipe

• A current health status value for Exchange Online (e.g., serviceOperational).
• Awareness of any active incidents, advisories, or issues impacting the service.
• A scriptable baseline you can schedule or integrate into monitoring pipelines (PagerDuty, Teams webhooks, ITSM tooling).
• Evidence to either escalate to Microsoft or pivot to tenant-level troubleshooting.

Warnings and gotchas

• Health is tenant-scoped but not user-scoped. A serviceOperational status does not guarantee every user is unaffected — individual mailbox, transport rule, or licensing issues can still cause symptoms.
• Do not rely solely on health overviews for SLAs. The healthOverviews endpoint is a rollup. For detailed incident data, query /admin/serviceAnnouncement/issues and /admin/serviceAnnouncement/messages.
• Permissions matter. The app or user context must have ServiceHealth.Read.All. Delegated read attempts without this scope will return 403.
• Caching. Microsoft updates service health in near-real-time, but there can be a short delay between an incident starting and it appearing in the API.
• Avoid aggressive polling. Poll no more than once every 1–5 minutes to stay well within Graph throttling limits.