Microsoft 365 Tenant-Wide Service Health Incident — Platform Outage Affecting All Users
A tenant-wide Microsoft 365 service health incident is a platform-level outage or degradation affecting one or more M365 services (Exchange Online, Teams, SharePoint Online) across an entire tenant. These incidents originate on Microsoft's infrastructure and resolution depends on Microsoft engineering. Administrators must confirm incident scope via the Service Health Dashboard, rule out tenant-specific misconfigurations, communicate status to stakeholders, and apply any published workarounds while awaiting Microsoft remediation.
Indicators
- Multiple users across different locations and devices unable to access one or more Microsoft 365 services simultaneously
- Microsoft 365 admin portal Service Health Dashboard shows an active advisory or incident for the affected workload
- Microsoft 365 service status page (status.office365.com or status.office.com) reflects degraded or outage state
- User-reported errors: inability to send/receive email, sign-in failures, Teams calls dropping, SharePoint pages timing out — affecting all or most users tenant-wide
- No recent tenant-side changes (policy, configuration, licensing) correlating with onset of the issue
Likely causes
- Microsoft datacenter infrastructure failure affecting the tenant's assigned service region
- Microsoft platform-level software deployment or update introducing a regression across tenant workloads
- Microsoft network or DNS infrastructure degradation affecting service reachability
- Downstream dependency failure within Microsoft's infrastructure (e.g., Azure Active Directory / Entra ID outage cascading into M365 workloads)
- Capacity or throttling events on Microsoft's side affecting tenant service tiers
Diagnostic steps
-
Navigate to admin.microsoft.com > Health > Service Health and identify any active incidents or advisories affecting your tenant's workloads. Note the incident ID (e.g., EX123456).Confirms whether Microsoft has acknowledged a platform-level incident affecting the tenant, determining whether remediation is tenant-side or awaiting Microsoft.
-
Cross-reference with the public Microsoft 365 status page at https://status.office365.com and the @MSFT365Status Twitter/X account to verify incident scope and whether other tenants are affected.Validates that the issue is a genuine Microsoft-side incident and not an isolated tenant misconfiguration or regional network problem.
-
Rule out tenant-specific root causes: run 'nslookup outlook.office365.com' to verify DNS resolution for M365 endpoints, confirm no recent conditional access policy changes, check hybrid connector health in Exchange Admin Center if applicable.Ensures the impact is not caused by tenant-side configuration change, DNS failure, or local network issue masquerading as a platform outage.
-
Test from a mobile device on cellular network (bypassing corporate network) to isolate local network issues from platform-level outages.Differentiates between local network/firewall issues and genuine Microsoft service degradation.
-
In Service Health Dashboard, select the active incident and review the incident detail page for latest Microsoft engineering update, affected services, workarounds, and estimated time to resolution (ETR).Provides authoritative incident timeline, scope, and any published workarounds that can be applied immediately to restore partial service.
-
If no incident is listed but tenant-wide impact is confirmed, open a Severity A (critical) support ticket via admin.microsoft.com > Support > New Service Request, providing impact scope, affected services, user count, and symptom details.Escalates the issue to Microsoft support for investigation when the incident has not yet been detected or published on the Service Health Dashboard.
-
Use Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com) to run connectivity tests for Exchange Online, Teams, or other affected services.Provides independent validation of service connectivity and identifies specific failure points in the connection chain.
Resolution path
- 1. Confirm the incident via the Service Health Dashboard — note the incident ID (e.g., EX123456) for all communications and support tickets.
- 2. Apply any Microsoft-published workarounds listed in the incident detail (e.g., switching to Outlook on the web if the desktop client is affected, routing mail through an alternate connector if Exchange Online transport is degraded).
- 3. Communicate incident status and ETR to stakeholders and affected users using an internal status page or email from an unaffected communication channel; reference the Microsoft incident ID.
- 4. If incident persists beyond the ETR or no ETR is published, escalate via Microsoft support ticket (Severity A) and request escalation to the Duty Manager if business impact is critical.
- 5. Once Microsoft resolves the incident, validate all affected services are fully restored (see Verification steps) and document the incident timeline for internal records and compliance requirements.
- 6. Review the post-incident report Microsoft publishes (typically within 5 business days) via Message Center for root cause analysis and any recommended tenant-side hardening.
Prevention
- Configure Service Health Dashboard email notifications for all critical workloads (admin.microsoft.com > Health > Service Health > Preferences) so administrators are alerted immediately when Microsoft publishes an incident
- Maintain a documented incident communication plan that includes the Microsoft 365 incident ID format, stakeholder distribution list, and escalation thresholds — rehearse this plan quarterly
- Subscribe to the Microsoft 365 Service Communications API (via Microsoft Graph) or a third-party M365 monitoring tool to enable automated alerting and dashboarding of service health state
- Maintain break-glass administrator accounts that are not federated or dependent on M365 services (e.g., cloud-only accounts with FIDO2 keys) to ensure admin portal access even when identity services are degraded
- Document alternate communication channels (e.g., SMS distribution list, separate email domain) that can be used when M365 services are unavailable
Tools
- Microsoft 365 admin center — Service Health Dashboard (admin.microsoft.com > Health > Service Health)
- Microsoft 365 public status page (https://status.office365.com)
- Microsoft 365 Message Center (admin.microsoft.com > Health > Message Center)
- Microsoft Support ticket portal (admin.microsoft.com > Support)
- nslookup / Resolve-DnsName — DNS resolution validation for M365 endpoints
- Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com)