Microsoft 365 Outage: How to Check Status, Tell If It Is Your Side, and Claim an SLA Credit

By The Uptime Report Team · Last reviewed: October 2026

A Microsoft 365 outage is confirmed in Service health in the admin center, not on the public status page. Below 99.9% monthly uptime, Microsoft's SLA credits 25% of the affected service's fee.

How do you check if Microsoft 365 is down right now?

Check the Service health page in the Microsoft 365 admin center first: it lists the incidents and advisories that affect your own tenant. If no admin can sign in, Microsoft points to status.cloud.microsoft and the @MSFT365Status account on X. Neither public channel is a full incident feed, so a quiet public page does not prove that Exchange Online or Teams is healthy for your users.

• Tenant status: admin.microsoft.com, then Health > Service health. The admin view of incidents for your own tenant (the Graph API reads the same data); it needs an admin role.
• Public fallback: status.cloud.microsoft. Updated only when problems stop admins from reaching Service health, so “Available” there proves little.
• Microsoft’s network: connectivity.office.com/status. Microsoft says this view “shows any significant health issues with Microsoft’s global network”; it does not list tenant incidents.

1. Sign in at admin.microsoft.com and open Health > Service health. Microsoft Learn says people assigned the Service Support admin or Helpdesk admin role can view it.
2. Read the two lists at the top. “Issues for your organization to act on” holds problems detected in your environment. “Active issues Microsoft is working on” holds Microsoft’s own incidents and advisories.
3. Open the matching issue. Note its ID, estimated start time, status and the Issue origin field, which says whether the problem was found at Microsoft or in your environment.
4. Subscribe to updates. Under Customize > Email, each admin can send notifications to up to two addresses. Microsoft’s service health and continuity page says incident updates arrive hourly unless the post states another cadence.
5. If the admin center will not load, open status.cloud.microsoft and the @MSFT365Status account.
6. If nothing is posted, select Report an issue on the Service health page. Microsoft compares the report with data from other organizations and adds an incident or advisory if the problem started in its service.

The public page is narrower than its role as a status page suggests. The RSS feed behind it describes the Microsoft 365 card in Microsoft’s own words: “This site is updated when service issues are preventing tenant administrators from accessing Service health in the Microsoft 365 admin center.” When we read the feed at 09:56 UTC on 20 October 2026, the card’s status was “Available”.

What can an admin see during a Microsoft 365 outage, and what stays hidden?

An admin sees Microsoft’s incidents and advisories for subscribed services, each with an ID, status, user impact and origin, plus 7 or 30 days of resolved history. An admin does not see planned maintenance on that page, does not get a post-incident review for every incident, and gets the Exchange Online monitoring dashboards only with 5,000 or more qualifying licenses.

Microsoft’s service health definitions split problems into two types. An advisory means a problem “affecting some users, but the service is still available”. An incident means “the service or a major function of the service is unavailable”, for example users who cannot send and receive email or sign in. Each issue carries one of 9 statuses, from Investigating to Post-incident report published; False positive means Microsoft confirmed the service was healthy or the cause sat outside it.

How can an MSP read service health for every client tenant?

Use the Microsoft Graph service communications API. Three read endpoints cover status, issues and post-incident reviews, and all three need only the ServiceHealth.Read.All permission. An MSP can reach each client tenant either through GDAP with a technician who holds Service support administrator, or through an app registration that a client admin consents to. Poll on a schedule and archive, because the admin center keeps 30 days.

For delegated calls, Microsoft Graph checks that the signed-in user holds a Microsoft Entra admin role in the tenant being read. Partner Center’s GDAP role guidance describes Service support administrator as able to “read service health information and manage support requests”, and names it the least-privileged role for submitting a support ticket on a customer’s behalf, so one GDAP role covers both reading incidents and filing the follow-up ticket.

The application route suits an unattended poller: register one app, have an admin in each client tenant grant ServiceHealth.Read.All, and read with the app’s own identity. Either way, store each issue ID (for example EX226792 in Microsoft’s sample response) against the client in your PSA; that ID is the outage identifier Partner Center asks for in a credit request, so it belongs on the client’s ticket in the PSA, the ticketing and billing system described in our MSP software guide.

Is the Microsoft 365 outage on your side or Microsoft’s?

Treat it as a Microsoft outage only when Service health shows an active incident or advisory for the affected service, or when the public status card reports one while admins are locked out. Microsoft’s service description says interruptions caused by third-party providers or by “changes made within customer managed environment” are not service incidents, so those problems stay with you.

Microsoft’s monitoring documentation names three origins: Microsoft 365 infrastructure, third-party infrastructure your tenant depends on, and your own infrastructure. Its example of the third type is users who cannot reach Exchange Online because an on-premises token service has an expired certificate. The decision table below holds the same logic as the flowchart.

What does the Microsoft 365 SLA promise during an outage?

Microsoft’s Service Level Agreement for Online Services, October 2026 version, commits Exchange Online, SharePoint Online, OneDrive, Microsoft Teams and Microsoft 365 Apps to 99.9% monthly uptime. Below that, the credit is 25% of the affected service’s monthly fee, 50% below 99%, and 100% below 95%. Teams Phone and Calling Plans start crediting below 99.999%.

Each service defines downtime narrowly. For Exchange Online it is time when users “are unable to send or receive email with Outlook Web Access”, so an Outlook desktop fault alone does not count. For the Microsoft 365 Apps it is time when apps enter reduced functionality mode “due to an issue with Office 365 activation”, not a crash or a bad update.

The exclusions narrow what counts as downtime. The SLA does not apply to failures “external to our data centers, including at your site or between your site and our data center”, to third-party software or services, or to latency “without actual service unavailability”. The Exchange Online availability terms also exclude tenant misconfiguration and incidents induced by an ISP or on-premises systems.

Credits are the “sole and exclusive remedy”, capped at that service’s monthly fee, and never cover lost revenue. Our 99.9% uptime research puts an 8-hour Exchange Online credit at $2.00 per user against $302.48 of payroll for the same day. Microsoft’s Partner Center credit policy adds that “advisory incidents aren’t typically eligible for SLA credits”, so an issue posted only as an advisory is not typically eligible.

How is a Microsoft 365 service credit calculated, and who files the claim?

Microsoft measures most Microsoft 365 services in user-minutes: the minutes in the month, less scheduled downtime, multiplied by the number of users. Each incident counts its length multiplied by the users it affected. An outage that reaches 10 of 50 users counts one fifth as much, so a partial outage can earn nothing. CSP customers claim through their provider in Partner Center; everyone else files with Microsoft support.

The worked example uses a 50-user tenant and a 30-day month of 43,200 minutes, or 2,160,000 user-minutes, with the SLA’s formula: (user-minutes minus downtime user-minutes) divided by user-minutes, times 100.

The share of users matters as much as the clock. The table below gives the outage length at which each tier starts, for a single outage in a 30-day month; the heat map plots every combination and marks the five worked scenarios.

Neither the SLA nor Partner Center publishes how a suite price is split across its services. Partner Center gives the one documented rule: if a customer with an Office 365 suite “only experienced a SharePoint outage, the SLA credit is approved only for SharePoint and not the customer’s entire plan”. Suites such as Business Premium, compared in our Microsoft 365 business plans guide, are therefore credited service by service, not on the full per-user price.

For a direct claim, the SLA requires these items; missing information “will result in claims being rejected”:

1. A detailed description of the incident (the Service health issue ID helps tie it to Microsoft’s record).
2. The time and duration of the downtime.
3. The affected resource names.
4. The number and locations of affected users.
5. A description of the errors users saw.
6. Send it by the end of the month after the incident month: an incident on 15 February must be claimed by 31 March. Microsoft says it typically processes claims within 45 days.

Only one credit is allowed per service per month, and if one incident breaks two service levels for the same service you must pick one. The SLA’s own example: Exchange Online and SharePoint Online bought separately, not as a suite, can each earn a credit for the same incident.

How reliable has Microsoft 365 been, by Microsoft’s own numbers?

Microsoft publishes a quarterly worldwide uptime figure for Microsoft 365. From Q1 2022 to Q2 2026, 17 of 18 quarters were at 99.927% or higher. Q1 2026 fell to 99.526%, the only quarter in Microsoft’s table below 99.9%, before Q2 2026 recovered to 99.994%. Microsoft’s table does not name the incidents behind any quarter.

To put Q1 2026 in time: a 90-day quarter has 129,600 minutes, and 0.474% of that is about 614 minutes, or roughly 10 hours 14 minutes of downtime if every user had been affected equally (our arithmetic). Microsoft notes the figures do not apply to U.S. Government DoD and GCC High tenants.

A worldwide average is not your tenant’s number: the SLA is assessed per service, per tenant, per calendar month, so a quarter above 99.9% worldwide can still hide a month below 99.9% for one region.

Which Microsoft 365 outages has Microsoft documented in public post-incident reviews?

Microsoft 365 post-incident reviews are delivered inside each tenant’s Service health, not on a public page. The public record is Azure status history, which keeps reviews for 5 years. Of the 82 reviews there, dated 27 October 2021 to 30 September 2026, 13 state that Microsoft 365 services were affected. By our coding of Microsoft’s stated triggers, 7 of those 13 trace to a Microsoft change, automation or software defect.

The timeline shows the reviews do not explain Microsoft’s worst quarter: none of the 13 falls in Q1 2026, when worldwide uptime dropped to 99.526%. Azure Front Door, Microsoft’s global edge and content delivery network, appears in 3 of the 13 reviews: 30 July 2024, 5 August 2024 and 29 October 2025. The October 2025 review lists Microsoft 365 alongside Entra ID, Purview and Dynamics 365 among the affected services and points tenants to incident MO1181369 in Service health.

The dependency also runs the other way. Microsoft’s review of a 29 May 2026 Azure OpenAI incident (tracking ID LYXT-C1Z) says the trigger was a change in an upstream API layer used by Microsoft 365 for Copilot-related experiences; it does not describe Microsoft 365 user impact, so it is not counted in the table.

What should an IT team or MSP do during a Microsoft 365 outage?

Confirm the incident in Service health, record what the SLA claim will need while the outage is live, follow any workaround Microsoft posts, and tell users through a channel that does not run on Microsoft 365. The SLA excludes downtime caused by continuing to use a service after Microsoft advised you to change how you use it, so posted workarounds carry contractual weight.

1. Confirm and capture. Copy the issue ID, estimated start time and affected services from Service health.
2. Log impact. Record the number and locations of affected users, the exact error text, and when each symptom started and stopped. These are items (ii) to (v) of the SLA claim.
3. Test Outlook on the web. Exchange Online downtime is defined on Outlook on the web, so a working web client shortens the claimable window.
4. Apply posted workarounds. Advisories often include one, per Microsoft’s definitions.
5. Communicate off-platform. If Exchange Online and Teams are both affected, use SMS, a phone tree or a status page hosted elsewhere.
6. Watch for the review. For broad incidents, expect a preliminary PIR within 48 hours of resolution and a final one within 5 business days.
7. File the claim before the end of the following month, and keep the PIR with it.

What should an MSP put in the client agreement about Microsoft 365 outages?

Write down that Microsoft 365 availability is Microsoft’s 99.9% commitment, not yours, and say who claims the credit and where it goes. In CSP, Partner Center puts the credit on the provider’s invoice and requires an emailed request from the client’s own domain, so the agreement should require that email and say whether the credit is passed through.

• Uptime language: quote the SLA tiers per service (25% below 99.9%, 50% below 99%, 100% below 95%) and note that credits are the “sole and exclusive remedy”.
• Credit pass-through: state whether a credit on your Partner Center invoice is passed to the client in full, and within which billing cycle.
• Client duty: the client sends the credit request from an address on the affected tenant’s domain in time for you to file within one month after the end of the billing month of the incident; Partner Center says email from a personal address “isn’t acceptable”.
• Access: keep a GDAP relationship that includes Service support administrator, the least-privileged role for filing support tickets for the client and one that can also read service health.
• Evidence: you record affected user counts, locations and error text during the outage, matching what Partner Center lists as evidence of customer impact.

A credit is capped at the affected service’s monthly fee, so any continuity promise you make to the client is your own cost to price, separate from Microsoft’s SLA; our managed IT services pricing guide covers per-user pricing for those agreements.

How we compiled this

We compiled this from 16 primary documents accessed in October 2026: Microsoft’s Service Level Agreement for Online Services (October 2026 Word edition), 13 Microsoft Learn pages on service health, service continuity, Microsoft 365 monitoring, Exchange Online monitoring, admin roles, four Graph service communications API pages, Partner Center credit requests, GDAP role guidance, the network connectivity test and the Remote Connectivity Analyzer, the status.cloud.microsoft RSS feed, and all 82 post-incident reviews in Azure status history, downloaded through its history endpoint and searched for Microsoft 365 terms, with every match checked by hand. News reports were not used for any incident fact, and we did not test services or survey users.

Frequently asked questions

Is Microsoft 365 down right now?

Check Service health in the Microsoft 365 admin center for incidents affecting your tenant. If no admin can sign in, check status.cloud.microsoft and @MSFT365Status on X. The public page is updated only when admins cannot reach Service health, so a green card there does not rule out an outage for your users. Regular users cannot see Service health; ask an admin.

How do I check Microsoft 365 service health without admin access?

Users without an admin role cannot open Service health. Microsoft says people with the Service Support admin or Helpdesk admin role can view it (Microsoft Learn), so an organization can give that role to a help desk lead. Outside the tenant, the public options are status.cloud.microsoft, which covers admin center access problems, and the @MSFT365Status account for widespread incidents.

Are Microsoft 365 advisories eligible for an SLA credit?

Usually not. Microsoft’s Partner Center credit policy says advisory incidents “aren’t typically eligible for SLA credits”. An advisory means the service is still available to most users, while the SLA counts only downtime such as being unable to send or receive mail in Outlook on the web. Log the issue ID anyway, because Partner Center asks for the outage incident ID in every credit request.

Can I get Microsoft 365 outage alerts by text message or in Teams?

Service health itself sends email to up to two addresses per admin, filtered by service and by incident or advisory, and the Microsoft 365 Admin app adds push notifications (Microsoft Learn). Neither is a Teams or SMS channel. For those, poll GET /admin/serviceAnnouncement/issues in Microsoft Graph with ServiceHealth.Read.All and forward each new issue ID to the channel you use.

Does Microsoft 365 GCC High use the same uptime figures and status tools?

Not entirely. Microsoft states its published quarterly uptime figures do not apply to U.S. Government DoD and GCC High (Microsoft Learn). Service health data for those clouds is read through separate Graph endpoints: graph.microsoft.us for GCC High and dod-graph.microsoft.us for DoD (Microsoft Graph docs). The network connectivity test lists a US Government (GCC) version with network health status.

How long do Microsoft 365 outages last?

In the 13 Azure post-incident reviews that name Microsoft 365 impact, stated impact windows ran from 1 hour 25 minutes (Azure AD sign-in, 16 December 2021) to 24 hours 50 minutes (South Central US power event, 26 December 2024). Three of the 13 lasted more than 24 hours. Source: Azure status history, accessed October 2026.

Why is Outlook not working when Microsoft 365 is up?

If Outlook on the web sends and receives but Outlook desktop does not, the fault is usually the client, profile or local network, not Exchange Online. The Exchange Online SLA defines downtime as users being unable to send or receive email with Outlook on the web. Microsoft’s Remote Connectivity Analyzer has an Outlook Connectivity test for the desktop path.

Sources

1. Microsoft, Service Level Agreement for Microsoft Online Services (October 2026, English Word edition). Accessed October 2026.
2. Microsoft Learn, Partner Center, Request a credit from Microsoft. Accessed October 2026.
3. Microsoft Learn, Partner Center, GDAP role guidance (least-privileged roles by task). Accessed October 2026.
4. Microsoft Learn, How to check Microsoft 365 service health. Accessed October 2026.
5. Microsoft Learn, Service health and continuity (Microsoft 365 service description). Accessed October 2026.
6. Microsoft Learn, Learn about Microsoft 365 monitoring. Accessed October 2026.
7. Microsoft Learn, Exchange Online monitoring for Microsoft 365. Accessed October 2026.
8. Microsoft Learn, About admin roles in the Microsoft 365 admin center. Accessed October 2026.
9. Microsoft Learn, Working with service communications APIs in Microsoft Graph. Accessed October 2026.
10. Microsoft Graph v1.0, List healthOverviews. Accessed October 2026.
11. Microsoft Graph v1.0, List issues. Accessed October 2026.
12. Microsoft Graph v1.0, serviceHealthIssue: incidentReport. Accessed October 2026.
13. Microsoft Learn, Microsoft 365 network connectivity test tool (incl. network health status). Accessed October 2026.
14. Microsoft Learn, Remote Connectivity Analyzer tests for Exchange Online. Accessed October 2026.
15. Microsoft, Microsoft Admin Center Status RSS feed (status.cloud.microsoft). Accessed October 2026.
16. Microsoft Azure, Azure status history (post-incident reviews). Accessed October 2026.
17. Microsoft 365 Status (@MSFT365Status) on X. Accessed October 2026.