3.1 Monitoring Service Health & Notifications

Quick Answer: The Service Health dashboard in the Microsoft 365 admin center (Home → Health → Service health) shows active incidents, advisories, and resolved issues for the workloads your tenant is licensed for. Configure notifications under Settings → Org settings → Service health so the right admins get email, SMS, or portal alerts when Microsoft 365 degrades.

Microsoft 365 is a multi-tenant SaaS platform, and Microsoft operates the underlying infrastructure — but the administrator is still accountable for knowing when a service is degraded, communicating impact to users, and verifying restoration. The Service Health dashboard is the primary out-of-the-box tool for that situational awareness.

Where to Find It

In the Microsoft 365 admin center, navigate to Health → Service health. (Skilled admins can also reach it directly via admin.microsoft.com/AdminPortal/Home#/servicehealth.) The dashboard is scoped: it only displays entries for services your tenant has licensed. A tenant without Exchange Online, for example, will not see Exchange incidents even if a global Exchange outage is in progress.

What the Dashboard Shows

Each entry on the Service Health dashboard falls into one of three categories:

• Service incident — an active or recently resolved event where the service is degraded or unavailable for some users. Each incident carries an IH (Incident) number (e.g., IH123456), a status (Investigating, Restoring service, Service restored, Post-incident report published), an issue type, a user impact statement, and an update history timeline.
• Advisory — a non-urgent notification. Advisories cover planned maintenance that has no expected user impact, minor transient issues Microsoft is monitoring, or informational notes. Advisories do not generally interrupt service.
• Resolved issue — an incident or advisory that has been closed, retained on the dashboard for a period so admins can review the post-incident report and timeline.

Status icons summarize each row: a green check indicates healthy, an orange triangle indicates an advisory, and a red diamond or exclamation icon indicates an active incident with user impact.

Reading an Incident's Details

Selecting an incident opens a detail pane with the headline issue, the affected workload, the scope of user impact (tenant-wide, a region, a feature subset), and a chronological update history. The IH number is the authoritative reference — quote it in support tickets and user communications so Microsoft Support can correlate your tenant with the broader incident. The update history is append-only: each new entry is timestamped (UTC) and shows the current status and any mitigation actions.

Admins on Targeted Release may see incidents affecting their users earlier than the general release population, because their tenant is in the first wave of a rollout. This is one of the operational reasons to put a small pilot group of IT staff on Targeted Release.

Configuring Notifications

Email, SMS, and portal notifications are configured under Settings → Org settings → Service health → Email notification settings. Available options include:

• Recipients — specific admin email addresses, or a Microsoft 365 group / distribution list. Best practice is a dedicated m365-oncall group so on-call rotation changes do not require reconfiguring the alert.
• Channels — email, phone (SMS text), and in-portal notifications. SMS is useful for critical incidents outside business hours.
• Alert scope — choose to alert on incidents only, advisories only, or both. Most organizations alert on incidents only for SMS, and on incidents plus advisories for email, to limit noise.
• Service filter — restrict alerts to specific workloads (e.g., Exchange Online, Microsoft Teams, SharePoint Online) so a Teams-only admin does not receive Exchange noise.

Notification delivery requires the recipient to be a Microsoft 365 administrator with Service Health read permissions. Global admins and Service Support admins can view and configure; custom roles with ServiceHealth.Read can view.

Service Health vs Message Center

A common MS-102 exam trap is conflating Service Health with the Message Center. They answer different operational questions.

The Message Center publishes posts about upcoming feature changes, retirements, and admin action items, often with a Act by date. Service Health posts about service degradation. Both flow through the same Service Communications API for programmatic consumption.

Programmatic Monitoring: Service Communications API

For organizations with a NOC, a ticketing system, or a custom status dashboard, the Service Communications API in Microsoft Graph exposes Service Health and Message Center data programmatically. The relevant endpoints live under https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/ — healthOverviews for the per-service current status, issues for the incident/advisory list, and messageCenter for planned-change posts.

The API requires an access token with ServiceHealth.Read.All (delegated or application). Application permissions are useful for headless monitoring daemons that post to Teams channels or open PagerDuty incidents. This API is the same data source the admin center UI uses, so programmatic alerts and the portal are consistent.

Operational Best Practices

• Maintain a dedicated m365-oncall group for notifications; rotate membership with the on-call schedule.
• Document the escalation path when an incident is confirmed: who informs executives, who updates the status page, who drafts the user communication.
• After any major incident, read the post-incident report (PIR) Microsoft publishes on the resolved entry — it explains root cause and remediation and is frequently referenced in MS-102 item stems.
• Combine Service Health monitoring with Microsoft 365 usage analytics to correlate degradation with user-reported complaints.