If you've ever clicked on an email attachment in Outlook Web App (OWA) and watched it spin forever, or worse, get a cryptic error message instead of your file, you're not alone. A Microsoft 365 service incident affecting OWA can suddenly block every user in your organization from downloading attachments, and it usually happens at the worst possible time. This guide walks you through exactly what's happening, how to confirm it's a service incident, and every troubleshooting step you can take right now while Microsoft works on a fix.

What Is an OWA Service Incident?

Microsoft 365 runs on a globally distributed cloud infrastructure. Outlook Web App, now officially called Outlook on the web, relies on dozens of interdependent backend services to deliver email, render previews, and serve attachment downloads. When one or more of those services degrades or fails, Microsoft flags it as a service incident in the Microsoft 365 Admin Center.

An OWA attachment-download incident specifically means that the service responsible for fetching, streaming, or decrypting file attachments from Exchange Online has hit a problem. From your perspective as a user, this shows up as:

The attachment download button does nothing when clicked
A "Download failed" or "Something went wrong" error toast appears
The file preview loads but the download link returns a 403, 503, or timeout error
The browser's network console shows requests hanging indefinitely or failing with HTTP errors
The issue affects all users in the tenant, not just one person or one browser

The key distinction between a service incident and a local problem is scope. If only one user on one machine is affected, you're probably dealing with a browser issue or a permissions problem. If the whole organization woke up to broken attachments this morning, a service incident is almost certainly the culprit.

Why Does This Happen? The Technical Causes

Understanding why OWA attachment downloads fail during a service incident helps you make smarter decisions about workarounds. Here are the most common root causes Microsoft has documented over the years:

1. Exchange Online Transport Service Degradation

When the Exchange Online transport layer experiences latency spikes or partial outages, attachment metadata, the signed URLs that tell OWA where to fetch the file, can become invalid or expire before the download begins. The result is a broken download even though the email itself loads fine.

2. SharePoint/OneDrive Integration Failures

Modern OWA increasingly routes large attachments and OneDrive-linked files through SharePoint Online infrastructure. If SharePoint's file-serving APIs are degraded, OWA loses the ability to stream those files to the browser.

3. Azure Active Directory Token Failures

Every attachment download is authorized by a short-lived token issued by Azure AD (now Microsoft Entra ID). If the token-issuance service is under stress, tokens can fail to generate or arrive malformed, and your browser gets a 401 Unauthorized response that reads like a download failure.

4. CDN or Blob Storage Throttling

Microsoft stores email attachments in Azure Blob Storage and serves them via their global CDN. During high-traffic periods or infrastructure events, certain Azure regions can experience throttling or partial unavailability, causing downloads in affected regions to silently fail.

5. Certificate or TLS Relay Issues

Less common but documented: TLS certificate renewals or relay misconfigurations on Microsoft's edge nodes can cause download requests to be rejected mid-stream, appearing to the user as a timeout or a network error.

Good to know: None of these issues are caused by anything you or your admin did. They are infrastructure-level events on Microsoft's side. Your job right now is to confirm the incident, apply workarounds, and reduce user frustration while the fix is deployed.

Step 1, Confirm It's Actually a Service Incident

Before you spend an hour troubleshooting browser caches and firewall rules, spend five minutes confirming the problem really is on Microsoft's end. This saves everyone time.

Check the Microsoft 365 Admin Center Service Health Dashboard

Open a browser and navigate to admin.microsoft.com. Sign in with your global admin or service support admin credentials. In the left navigation pane, go to Health > Service health. Look for any active incidents under the Exchange Online or Microsoft 365 suite rows. An active incident will show a red or orange indicator with a description like "Users may be unable to download attachments in OWA."

Read the Incident Detail Page

Click the incident ID (it will look something like EX123456) to open the full detail view. This page tells you the scope of impact, affected regions, current status (investigating / mitigating / resolved), and Microsoft's estimated time to resolution. Screenshot this page, you'll want it for your ticketing system and for communicating with affected users.

Check Microsoft 365 Status on Twitter / X and the Status Page

If you don't have admin credentials handy, check status.office365.com or follow @MSFT365Status on X (formerly Twitter). Microsoft's communications team posts incident updates there in near real-time. This is also useful if you need to show non-technical stakeholders that the issue is known and being worked on.

Reproduce the Issue on Multiple Machines and Browsers

Try downloading an attachment from OWA on a different computer, using a different browser (try Edge, Chrome, and Firefox), and ideally on a different network (your phone's mobile data, for example). If the download fails consistently across all of these, you have strong confirmation that it's not a local client issue. If downloads work on mobile data but not your office network, your firewall or proxy might be intercepting traffic, note that for the advanced troubleshooting section later in this guide.

Important: Do not file a Microsoft support ticket saying "OWA is broken" without including the incident ID from the Service Health Dashboard. If an active incident already exists, the support team will simply reference the incident and close your ticket. Instead, file a ticket only if your tenant's impact seems more severe than what Microsoft describes, or if the incident is marked resolved but you're still seeing the problem.

Step 2, Apply Immediate Workarounds for Affected Users

Once you've confirmed a service incident, your priority is keeping people productive. Here are the best workarounds to deploy right now, ranked from easiest to most involved.

Use the Outlook Desktop Client Instead of OWA

The Outlook desktop application (part of Microsoft 365 Apps) uses MAPI over HTTPS to communicate with Exchange Online, a completely different code path than OWA's browser-based download flow. During most OWA attachment incidents, the desktop client continues to work normally. If your users have Outlook installed, ask them to switch there immediately. For users who don't have it installed, you can push a quick Teams or email announcement pointing them to the next option.

Try the Outlook Mobile App

The Outlook iOS and Android apps use the same MAPI/Exchange ActiveSync protocol as the desktop client. In the vast majority of OWA incidents, mobile attachment downloads are unaffected. Tell your users to temporarily switch to their phones or tablets for urgent attachment needs.

Ask Senders to Re-Send Attachments via OneDrive Sharing Links

If the original sender is internal to your organization, ask them to re-send the file using the "Attach as a OneDrive link" option in OWA or Outlook. When the file is shared as a OneDrive link rather than a true inline attachment, it's fetched directly from SharePoint Online rather than through the Exchange attachment pipeline. During Exchange-specific incidents, this path often still works.

Use OWA's "Open in App" Preview Instead of Direct Download

For Word, Excel, PowerPoint, and PDF attachments, try clicking the attachment and choosing "Open in Word Online" or "Open in Excel Online" instead of downloading. The Office Online rendering pipeline is separate from the attachment download pipeline and may be unaffected by the incident. From Word Online or Excel Online, you can then use File > Download a Copy to save the file locally.

Use Exchange Online PowerShell to Export Attachments (Admin Use)

For critical business attachments that absolutely cannot wait, an admin can use Exchange Online PowerShell to export the message and attachment directly. Connect using:

Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com

Then use the Export-Mailbox cmdlet or the Compliance Center eDiscovery export tool to pull the message to a PST file and extract the attachment. This is a last resort, but it works because it bypasses OWA's frontend entirely.

Quick communication template: Send this to affected users, "We're aware of an issue with downloading email attachments in Outlook Web App (OWA). This is a Microsoft 365 service incident (ID: [EX######]) being actively investigated by Microsoft. While they work on a fix, please use the Outlook desktop app or Outlook mobile to download attachments. We'll update you when the issue is resolved."

Step 3, Client-Side Fixes to Try While the Incident Is Active

Even during a service incident, some users find that client-side actions can restore functionality for them, particularly if the incident is partial (affecting some requests but not all). Walk your users through these steps before giving up on OWA entirely.

Hard Refresh the OWA Browser Tab

Press Ctrl + Shift + R (Windows/Linux) or Cmd + Shift + R (Mac) to force a hard refresh that bypasses the browser cache. This clears cached JavaScript and forces OWA to re-fetch all its front-end resources. Sometimes OWA's service worker or cached tokens become stale and a hard refresh resolves it.

Clear Browser Cookies and Cache for outlook.office.com

In Chrome, open DevTools (F12), right-click the refresh button, and select "Empty Cache and Hard Reload." Alternatively, go to Settings > Privacy and Security > Clear browsing data and clear cookies and cached files for the last hour. After clearing, sign back into OWA and retry the download.

Try OWA in a Private / Incognito Window

Browser extensions (especially ad blockers, privacy extensions, and VPN browser plugins) can interfere with OWA's download requests by blocking the signed Azure Blob Storage URLs. Open an InPrivate (Edge) or Incognito (Chrome) window, sign in fresh, and try the download. If it works in private mode, an extension is your culprit rather than, or in addition to, the service incident.

Check Your Browser's Download Permissions for OWA

In Chrome, go to Settings > Privacy and Security > Site Settings > Additional permissions > Automatic downloads and make sure outlook.office.com is allowed. In some corporate environments, group policy locks down automatic downloads and the browser silently blocks the file without showing a clear error.

Sign Out of OWA and Sign Back In

Click your profile picture in the top-right corner of OWA and select Sign out. Then go to outlook.office.com and sign in again with your credentials. This triggers a full token refresh, which can resolve auth-related download failures that sometimes linger even after Microsoft begins mitigating the incident.

Advanced Troubleshooting, When It's Not (Just) a Service Incident

Sometimes an OWA attachment issue runs parallel to a service incident, or persists after the incident is resolved. Here's how to dig deeper when the standard steps don't solve it.

Inspect the Network Request

Open your browser's DevTools (F12), go to the Network tab, and filter by XHR or All. Click the attachment download button and watch what request fires. Look for:

HTTP 403: The signed download URL expired or your account lacks permission to access the attachment. This can happen with protected/encrypted messages (IRM-protected) or cross-tenant sharing.
HTTP 503: A Microsoft backend service is unavailable, confirms the service incident.
CORS error: Your proxy or firewall is stripping CORS headers on responses from *.blob.core.windows.net, which is where attachments are served from.
Request cancelled immediately: A browser extension or content security policy is blocking the request before it even leaves the browser.

Check Your Proxy and Firewall Configuration

OWA attachment downloads originate from several Microsoft CDN and Azure Blob Storage domains. Your proxy or firewall must allow outbound HTTPS traffic (port 443) to:

*.blob.core.windows.net
*.sharepoint.com
attachments.office.net
*.officeapps.live.com

If your firewall is performing SSL inspection (deep packet inspection), it may be breaking the signed URLs that OWA uses for downloads. Check your firewall logs for blocked or modified requests to these domains during the time of the failure. Microsoft specifically recommends bypassing SSL inspection for Microsoft 365 endpoints, this is a common misconfiguration that surfaces as attachment download failures.

Verify IRM / Sensitivity Labels Are Not Blocking Downloads

If the emails in question have Information Rights Management (IRM) protection or Microsoft Purview sensitivity labels applied, the download behavior is controlled by your DLP policies. A sensitivity label with "Block download" or "Protect on download" settings can prevent OWA downloads even when the service is healthy. Check your DLP policies in the Microsoft Purview compliance portal under Information Protection > Labels > Label policies.

Test With a Different Microsoft 365 Account

Create a test message in your tenant with a simple text file attachment and ask another licensed user, ideally in a different Azure AD group, to try downloading it. If downloads work for one account but not another, the issue may be account-level: a corrupt browser session token, a conditional access policy applied to one user's group, or even a mailbox corruption issue.

Run the Microsoft Support and Recovery Assistant (SaRA)

Microsoft's free diagnostic tool, the Microsoft Support and Recovery Assistant, can automatically detect and fix many OWA and Outlook connectivity issues. Download it from aka.ms/SaRA, select Outlook as the product, and choose "I have problems with Outlook on the web (OWA)" when prompted. SaRA runs a series of automated tests against your account and tenant configuration and flags issues that require manual remediation.

Heads up: SaRA requires the user to run it on their own machine, it won't work if you try to run it as an admin on their behalf. Send the link directly to affected users with instructions to run it themselves.

Check for Conditional Access Policies Blocking the Session

If your organization uses Azure AD Conditional Access, certain policies can block download actions in OWA for users who are accessing from non-compliant devices or unrecognized network locations. In the Azure AD (Entra ID) portal, go to Security > Conditional Access > Sign-in logs and filter by the affected user. Look for any failed or interrupted sign-in events that reference an OWA session during the time of the reported issue.

After the Incident Is Resolved, Verification and Cleanup

Once Microsoft marks the incident as resolved in the Service Health Dashboard, don't just assume everything is working. Take a few minutes to verify and clean up.

Test Attachment Downloads Yourself First

Before broadcasting "we're fixed" to your users, send yourself a test email with a .docx, .pdf, and .xlsx attachment and confirm all three download successfully in OWA. Test from both Chrome and Edge to cover the two most common browsers in corporate environments.

Notify Users When Service Is Restored

Send a follow-up communication telling users OWA attachment downloads are working again. Ask them to report any persistent issues immediately. A small number of users may still experience problems if their browser has a cached bad session, remind them to try a hard refresh or clear their cookies if they're still seeing errors.

Review the Post-Incident Summary in the Admin Center

About 24–72 hours after resolution, Microsoft publishes a Post-Incident Review (PIR) in the Service Health Dashboard under the incident's detail page. The PIR explains the root cause, what Microsoft did to fix it, and what they're doing to prevent recurrence. Read it, it's genuinely useful for understanding your Microsoft 365 environment and can inform your own preventive measures.

How to Prevent User Disruption in Future Service Incidents

You can't prevent Microsoft service incidents, but you can dramatically reduce their impact on your organization with the right preparation.

Set Up Service Health Email Alerts

In the Microsoft 365 Admin Center, go to Health > Service health > Preferences and configure email notifications for Exchange Online incidents. You can have alerts sent directly to your IT helpdesk inbox so you know about incidents before your users start filing tickets. This alone cuts the average time between incident start and admin awareness from hours to minutes.

Ensure All Users Have the Outlook Desktop App Installed

The Outlook desktop client is your primary OWA fallback. Make sure every user in your organization, including those who primarily use OWA by preference, has Outlook desktop installed and configured. Verify this during your next device management cycle. If you use Intune, you can create a compliance report that shows which enrolled devices don't have Outlook installed.

Train Your Helpdesk on the Service Health Dashboard

Your Level 1 helpdesk team should know how to check the Service Health Dashboard before escalating an OWA ticket. Create a short runbook (even just a one-page PDF) that shows them exactly where to look and what to communicate to users during an active incident. This reduces noise tickets, sets user expectations correctly, and frees your senior engineers to work on real problems.

Keep Microsoft 365 Endpoints Allowlisted in Your Firewall

Review Microsoft's published Office 365 URL and IP address ranges page (available at aka.ms/o365ips) quarterly. Microsoft updates this list regularly, and attachment download failures are one of the most common symptoms when a new endpoint hasn't been allowlisted. Subscribe to the RSS feed for automatic updates when the list changes.

Consider a Third-Party Service Health Monitoring Tool

Tools like Microsoft 365 Message Center aggregators, Office 365 Monitor, or third-party platforms like Enow Analytics or Martello Vantage provide richer alerting and historical incident data than the built-in Admin Center. For organizations with strict SLAs or large user populations, these tools provide faster and more granular alerting.

Frequently Asked Questions

How do I know if the OWA attachment issue is a service incident or a problem on my end?

The fastest way is to check the Microsoft 365 Service Health Dashboard at admin.microsoft.com. If there's an active incident listed under Exchange Online, that's your answer. As a quick secondary check: if the problem affects all users in your organization across multiple browsers and devices, it's almost certainly Microsoft's infrastructure. If it only affects one user or one browser, start troubleshooting locally.

Can I download attachments from OWA on my phone while the desktop web app is broken?

Yes, in most cases. The Outlook mobile app and the mobile browser version of OWA use different protocols and server paths than the full web client. During Exchange Online attachment incidents, mobile access frequently continues working normally. Use this as your first workaround for time-sensitive attachments.

The Microsoft Service Health Dashboard shows the incident is resolved, but I still can't download attachments. What do I do?

Microsoft's resolution can take time to propagate across all Azure regions and CDN nodes. Wait 15–30 minutes after resolution is announced and try again. If it's still broken after 30 minutes, clear your browser cookies for outlook.office.com, sign out, and sign back in to force a fresh session token. If that doesn't work, run the Microsoft SaRA tool and check whether your firewall is blocking any Microsoft 365 endpoints. If all else fails, open a Microsoft support ticket and reference the incident ID, they can investigate why your tenant is still affected post-resolution.

Is there an SLA I can hold Microsoft to for OWA downtime?

Yes. Microsoft's Microsoft 365 Service Level Agreement guarantees 99.9% uptime for Exchange Online (which powers OWA). If your tenant experiences downtime below that threshold in a given month, you can file for a service credit. Credits are typically applied as future billing credits, not cash refunds. To claim a credit, you need to submit a request through the Microsoft 365 Admin Center within 30 days of the incident. Your Service Health Dashboard history is the evidence Microsoft will ask for.

Why do some users in my organization still have working downloads while others don't?

This happens frequently during partial or geographically scoped incidents. Microsoft's infrastructure routes user traffic based on their mailbox region and the nearest Azure datacenter. If an incident only affects certain Azure regions, users whose mailboxes are homed in unaffected regions will continue working normally. It can also happen if your users are in different Azure AD groups with different Conditional Access policies, or if some users are accessing OWA through a VPN that exits in a different geographic region.

Can my admin help me access a specific attachment that I urgently need right now?

Yes. Your Microsoft 365 admin can use Exchange Online PowerShell or the Microsoft Purview compliance portal's Content Search tool to locate and export specific messages, including their attachments, as a PST file. The admin then extracts the attachment and sends it to you through an alternative channel (like Teams). This bypasses OWA entirely and works even during severe service incidents. It requires admin credentials and appropriate permissions (eDiscovery Manager role), so reach out to your IT team with the sender, subject line, and approximate date/time of the email.

Does this kind of issue affect Outlook desktop and Outlook mobile too, or just OWA?

It depends on the specific incident. Most OWA attachment incidents are isolated to the web client because they affect the browser-based download pipeline (signed Azure Blob Storage URLs, OWA's JavaScript download handler, or the OWA-specific reverse proxy). The desktop client uses MAPI over HTTPS and the mobile app uses EAS or the Outlook Sync Engine, both of which are separate codepaths. However, some Exchange Online incidents are broader and do affect all clients simultaneously. The Service Health Dashboard will specify which services and clients are impacted.

Summary and Quick Reference

Let's bring it all together. If you or your users can't download attachments in OWA, here's the fastest path to resolution:

Check the Service Health Dashboard at admin.microsoft.com, look for active Exchange Online incidents.
If an incident is confirmed, switch affected users to Outlook desktop or Outlook mobile as a workaround.
For urgent files, ask senders to re-send via OneDrive sharing links, or use the Office Online "Open in app" option to access files without downloading.
Try client-side fixes (hard refresh, clear cache, incognito mode, sign out and back in), they sometimes help even during active incidents.
If the incident is resolved but the problem persists, check your firewall's Microsoft 365 endpoint allowlist, disable SSL inspection for Microsoft domains, and run the SaRA diagnostic tool.
After resolution, verify independently, notify users, and read Microsoft's Post-Incident Review to understand what happened.

OWA service incidents are frustrating precisely because they're completely outside your control. But with the right preparation, alerts configured, desktop clients installed, your helpdesk trained on the Service Health Dashboard, you can turn what used to be a chaotic hour of confused tickets into a calm, five-minute "here's the workaround, here's the timeline" communication. That's the difference between a service incident and a service disruption.

Bookmark these links: admin.microsoft.com/adminportal/home#/servicehealth (Service Health Dashboard) | aka.ms/SaRA (Microsoft Support and Recovery Assistant) | aka.ms/o365ips (Microsoft 365 URL and IP ranges) | status.office365.com (public status page, no login required)