Is Microsoft 365 down for you right now, or is your network to blame?
When email bounces or meetings won’t start, you need a fast, reliable way to confirm the outage.
This guide gives a live Microsoft 365 outage status snapshot—what the Service Health dashboard shows, which services and regions to check first, how severity labels and timestamps work, and the immediate steps admins should take.
Read on to stop guessing and act faster during any disruption.

Live Microsoft 365 Service Health Overview (Real-Time Status Snapshot)

A complete Microsoft 365 status snapshot always carries a UTC timestamp and lists every active incident in progress. The dashboard organizes entries by service (Exchange, Teams, SharePoint, OneDrive, Azure AD) with a severity label: Investigating, Service Degraded, Service Interruption, Restored, or Mitigated. You’ll see the incident ID (something like “MO1234567”), when the issue was first detected, the most recent update timestamp, and an estimated resolution time if available. Otherwise, it’ll just say “TBD” while the team figures things out.

Every incident record shows tenant scope and regional impact. If the outage is tenant-wide, the dashboard states “Worldwide.” When only specific datacenters are affected, those regions appear in a comma-separated list. Impact summaries spell out the affected user actions—”mailbox send/receive,” “sign-in failures,” “file sync stopped,” or “meetings can’t be joined”—so admins quickly grasp what their end users are experiencing.

Core services to verify first during any potential disruption:

• Exchange / Outlook (email and calendar services)
• Microsoft Teams (messaging, calls, meetings)
• OneDrive for Business (file sync and sharing)
• SharePoint Online (intranet sites and document libraries)
• Azure Active Directory (sign-in, authentication, identity services)

Each service operates across multiple global datacenters. Outages often target specific regions or infrastructure layers. A healthy status line shows green with no active incidents. When something’s wrong, you’ll see a yellow or red indicator, the severity classification, and a brief description of what Microsoft is doing to restore service.

How to Check Current Microsoft 365 Outage Status Across Official Channels

The fastest official route is the Service Health page inside the Microsoft 365 admin center. Navigate to Health > Service health, and you’ll see every active incident, advisory, and maintenance notice affecting your tenant. This view is tenant-specific. It only shows issues relevant to your organization’s subscriptions and region assignments, and it includes published timestamps and estimated resolution windows.

Microsoft also publishes updates through the Message Center (for feature advisories and configuration changes) and offers RSS feeds for automated polling. Email alerting can be configured at the tenant level to push notifications to admin inboxes whenever a new incident is posted or an existing one changes state. For programmatic access, the Service Health API and webhook integrations let third-party monitoring tools and custom dashboards pull live status data without manual browser checks.

Step-by-step admin verification:

1. Sign in to the Microsoft 365 admin center at admin.microsoft.com.
2. Navigate to Health > Service health from the left sidebar.
3. Review the “Active issues” tab for any entries marked Investigating, Service Degraded, or Service Interruption.
4. Click an incident ID to open the full detail pane. It shows start time, last update time, affected services, region list, and Microsoft’s current mitigation actions.
5. Confirm the “Last updated” timestamp is recent (within the past hour during active incidents). Check whether an estimated resolution time is provided or listed as “TBD.”

Understanding Microsoft 365 Outage Details and Impact Indicators

Every incident entry breaks down into several metadata fields: start time (UTC), last update time (also UTC), severity level, affected service and region, estimated time to resolution (ETA), and a brief summary of user impact. Severity levels follow a standard progression. “Investigating” means Microsoft has confirmed the problem and is diagnosing root cause. “Service Degraded” indicates partial functionality loss. Some users can still work. “Service Interruption” marks a broader failure affecting most or all tenant users in scope. “Restored” or “Mitigated” signals the fix is deployed and service is recovering, though residual symptoms may persist while traffic rebalances.

Impact scope tells you whether the issue hits all customers worldwide or only specific datacenters. For example, an entry might read “Affected regions: North America, East US 2, West US” to show localized disruption. Or it may simply state “Worldwide” when a shared platform component fails. The user-impact summary describes exactly what stops working: “mailbox send/receive,” “authentication requests timing out,” “file sync client repeatedly retrying,” or “meeting join button unresponsive.”

Update cadence matters during long incidents. Microsoft typically posts a fresh update every 30 to 60 minutes while engineers are actively working. The “Last updated” timestamp lets you see whether the team is still engaged or waiting for monitoring data. If the timestamp hasn’t moved in several hours and status remains “Investigating,” expect slower progress or a complex root cause requiring deeper infrastructure changes.

Microsoft 365 Outage Map and Regional Disruption Overview

The outage map plots affected datacenters as color-coded regions on a global view, with severity indicated by shade intensity. Green for healthy, yellow for degraded, red for interruption. Each plotted region shows the approximate percentage of impacted users when Microsoft has enough telemetry, often expressed as “less than 1%,” “approximately 5%,” or “majority of users in this region.” Datacenter groups are labeled by Azure region name (for example, East US, West Europe, Southeast Asia). Clicking a region opens a detail pane listing active incident IDs tied to that geography.

Region scoring aggregates incident severity and user-impact metrics to produce an overall health grade. When multiple services experience degradation in the same datacenter simultaneously, the map elevates the region to a higher alert color even if each individual incident is marked “Service Degraded” rather than “Service Interruption.” This rollup view helps global operations teams decide where to focus their troubleshooting and communication efforts first.

Common region-map indicators to watch:

• Color code — green (healthy), yellow (partial degradation), red (widespread interruption)
• Severity badge — listed alongside the region name, showing the highest active severity in that area
• Tenant count estimate — how many organizations see impact in that region, sometimes shown as a numeric range
• Datacenter group label — Azure region identifier (for example, “North America, East US 2”) so you can cross-reference with tenant placement

Historical Microsoft 365 Outage Trends and Common Root Causes

Microsoft maintains sortable incident logs inside the Service Health dashboard, typically covering the past 30, 90, and 365 days. Admins can export these records as CSV files for trend analysis, capacity planning, and internal SLA reporting. Each historical entry includes incident ID, start and end timestamps, total duration (calculated in minutes or hours), a root-cause summary (published post-incident), the number of affected tenants, and a list of impacted services and regions.

Most minor incidents (authentication glitches, isolated mailbox access failures, or single-region file-sync hiccups) resolve within one to four hours. Larger or multi-region outages, especially those tied to backend infrastructure, DNS routing, or certificate expirations, can stretch beyond 24 hours while engineers roll fixes across global datacenters and validate traffic recovery. Trend charts inside the dashboard show incident frequency over rolling windows, helping IT teams identify whether certain services or regions experience recurring problems.

Troubleshooting Microsoft 365 Issues During an Outage

Before assuming an outage is global, verify your local setup and network path aren’t the cause. Many reported “outages” turn out to be browser cache corruption, expired authentication tokens, or firewall rules blocking Microsoft endpoints. These checks take less than five minutes and can save hours of waiting for a fix that already exists on your side.

Quick troubleshooting steps to run immediately:

• Sign out and sign back in — clears stale tokens and forces a fresh authentication handshake with Azure AD
• Clear browser cache or try private/incognito mode — removes locally stored data that may conflict with updated service endpoints
• Test on a different network or device — confirms whether the problem follows your account or stays tied to one machine or office network
• Verify mailbox send/receive with a test message — send yourself an email from an external account to isolate whether inbound, outbound, or both paths are broken
• Check OneDrive sync client logs — open the sync app, click settings, and review recent errors; most sync issues log specific HTTP error codes or throttling messages

If all five checks pass and service still fails, the incident is likely on Microsoft’s side. At that point, open the Service Health dashboard and look for an active incident matching your symptoms and region.

Admin Actions During a Microsoft 365 Outage (Tenant-Level Guidance)

Admins should follow a structured response sequence to confirm impact scope, gather diagnostic data, and keep users informed. The Service Health page is your starting point. Check it before opening a support ticket or posting internal announcements, because Microsoft often publishes mitigation steps or workarounds in the incident detail pane that solve the immediate problem without further escalation.

After verifying an active incident, review the Message Center for any related advisories or configuration changes that might have triggered the issue. Next, confirm tenant-specific settings: verify DNS records for custom domains, check Conditional Access policies and sign-in logs in Azure AD, and review any recent configuration changes (new firewall rules, proxy updates, certificate rotations). These checks help rule out self-inflicted problems that coincide with a reported outage.

Step-by-step admin checklist:

1. Open Health > Service health in the admin center and note any active incidents matching reported symptoms.
2. Navigate to Health > Message center and scan for advisories published in the past 48 hours that mention the affected service.
3. Verify tenant configuration: check DNS settings (especially MX and autodiscover records), review Azure AD sign-in logs for authentication failures, and confirm no recent changes to Conditional Access or Exchange transport rules.
4. If no public incident is listed but users are affected, open a support request through Support > New service request, reference your tenant ID and the exact symptoms (timestamps, error codes, affected user count).
5. Communicate to your users with timestamps and scope: “As of 14:30 UTC, Microsoft reports Exchange send/receive issues affecting North America tenants. Estimated resolution: 16:00 UTC. Workaround: Use Outlook on the web instead of the desktop client.”

Keep communication factual and timestamp every update. Users appreciate knowing you’re monitoring the situation and will post new information as Microsoft publishes it.

Monitoring and Automating Microsoft 365 Outage Alerts

Programmatic monitoring eliminates manual dashboard checks and ensures your team learns about outages within minutes, not hours. The Service Health API exposes incident data in JSON format, returning current status, active incidents, historical records, and message-center advisories. Most enterprises poll the API every one to five minutes, compare the returned incident list against a cached snapshot, and trigger alerts when new incidents appear or existing incidents change severity.

PowerShell offers a lightweight option for smaller environments. The Get-MgServiceAnnouncementIssue cmdlet (part of the Microsoft Graph PowerShell SDK) retrieves active incidents and can be scheduled via Task Scheduler or cron to run every few minutes. Pipe the output to a monitoring script that checks for severity keywords (“Service Interruption” or “Service Degraded”) and posts to Slack, Teams, email, or a ticketing system when conditions match. For high-sensitivity environments, pair API polling with synthetic transaction tests (scripted mailbox send/receive, file upload/download, Teams meeting creation) to catch localized issues that don’t yet appear on the global status board.

Integration with platforms like PagerDuty, Datadog, or Azure Monitor turns raw status data into actionable alerts. Configure webhooks to receive push notifications from Microsoft’s Service Health API whenever an incident is created, updated, or resolved, removing the need for constant polling. These integrations also aggregate outage data with internal service metrics, giving operations teams a unified view of end-user impact and helping prioritize incident response when multiple systems fail simultaneously.

SLA, Uptime Metrics, and Service Credit Eligibility for Microsoft 365 Outages

Microsoft commits to 99.9 percent uptime for core Microsoft 365 services under standard enterprise agreements, which translates to roughly 43 minutes of allowed downtime per month. When actual availability falls below that threshold in a given billing period, eligible customers can request service credits, typically a percentage of the monthly subscription fee proportional to the shortfall. The exact calculation, eligibility rules, and claim deadlines are defined in your tenant’s service-level agreement (SLA) document, which you can review in the admin center under billing and subscriptions.

To request a credit, gather the incident IDs, start and end timestamps, and duration of each outage that contributed to the SLA miss. Submit the claim through the support portal within the specified window (often 30 to 60 days after month-end). Microsoft reviews tenant-specific telemetry to confirm the downtime, then applies the credit to a future invoice. Not all incidents qualify. Scheduled maintenance, issues caused by third-party networks outside Microsoft’s control, and problems originating from tenant misconfigurations are typically excluded. Keep accurate records of each outage’s published root cause and your own diagnostic logs to support the claim if Microsoft’s initial review disputes the downtime calculation.

Final Words

In the action, this guide showed how to read a live Microsoft 365 service health snapshot, where to check official channels, how to interpret incident details and regional maps, and what quick user and admin steps help during outages. It also covered automation and SLA basics.

Next steps: glance at the Service Health dashboard, run the five quick checks, and add API/webhook alerts. Keep an eye on estimated ETAs and incident updates, that’s how you turn microsoft 365 outage status into a manageable task. You’ll be ready.

FAQ

Q: Why is Microsoft 365 not working?

A: Microsoft 365 is not working most often because of a service incident (Microsoft-side outage), tenant configuration or DNS/authentication problems, or local network/client issues—check the Service Health dashboard first for confirmed incidents.

Q: Is there currently a problem with Microsoft Outlook today?

A: Whether Outlook has a problem today depends on the live Service Health status; check the Microsoft 365 Service Health or try Outlook on the web and your admin’s Message Center to see if it’s a widespread outage or tenant-specific.

Q: How to check Microsoft outage status?

A: To check Microsoft outage status, open the Microsoft 365 Admin Center’s Service Health, review Message Center posts, subscribe to RSS/email alerts, or use the Service Health API/webhooks for programmatic, real-time updates.