Lessons from the November 2026 Microsoft 365 Outage: Designing Resilient OneDrive Transfers
Incident handling, Microsoft Graph throttling, resumable jobs, and the limits of cloud-to-cloud backup during a provider outage.
On November 12–13, 2026, a major Microsoft 365 service disruption exposed a familiar dependency: applications built on a cloud platform are only as reachable as the platform's identity, metadata, and file APIs.
Microsoft tracked incidents under MO1550821 (broader Microsoft 365 connectivity) and EX1550543 (Exchange Online). Public notices in Japan documented trouble accessing OneDrive alongside other Microsoft 365 applications; Hitotsubashi University's notice is one example.
The incident's reported infrastructure symptoms included unexpectedly unavailable servers and increased load. Those are incident reports, not proof that every Microsoft Graph endpoint failed or that any particular HTTP status code was widespread. What follows is an engineering playbook for the kinds of failures cloud-transfer systems may encounter during an outage.
1. Separate a provider incident from an application defect
A transfer failure can have several causes. Classify them before retrying:
| Signal | Possible interpretation | Safer first action |
|---|---|---|
429 Too Many Requests | API throttling | Honor Retry-After; reduce demand |
503 Service Unavailable or 504 Gateway Timeout | Temporary backend/capacity problem | Bounded retries and incident awareness |
| Network timeout / connection reset | Transient network or upstream issue | Retry safely; record attempt and checkpoint |
401 Unauthorized | Expired or invalid authorization, sometimes alongside access issues | Inspect the response and token flow; don't blindly rotate credentials |
403 Forbidden | Missing permissions, policy, or access restriction | Investigate authorization and tenant policy; don't treat as generic throttling |
These are general diagnostic examples, not a list of confirmed errors from the November incident. Microsoft documents their Graph error semantics separately.
For Microsoft 365 tenants, first correlate error spikes with Service Health and incident notices. Record timestamps, endpoint, tenant or account scope, sanitized error code, and request ID. Avoid logging OAuth tokens or file contents.
2. Respect Retry-After before exponential backoff
A naive retry loop can turn a bad incident into a worse one. Microsoft Graph's throttling guidance says to use Retry-After when supplied for 429 responses; otherwise, an exponential-backoff strategy is recommended.
A simplified policy—not a production-ready library—might look like this:
function retryDelayMs(attempt, retryAfterSeconds) { if (Number.isFinite(retryAfterSeconds) && retryAfterSeconds >= 0) { return retryAfterSeconds * 1000; } const capMs = 60_000; const baseMs = Math.min(capMs, 1000 * 2 ** attempt); return Math.floor(Math.random() * baseMs); // full jitter } function shouldRetry(status) { return status === 429 || status === 503 || status === 504; } Real systems also need a retry budget, request deadlines, cancellation, respect for HTTP-date-form Retry-After, and careful distinction between retry-safe reads and operations that create side effects. Do not blindly replay a non-idempotent upload or finalize request. SDKs may already retry some Graph requests automatically, so check for double retry layers.
3. Resume work instead of restarting entire libraries
Resilience comes from durable state:
- Give each transfer a stable task ID and store per-item progress.
- Persist checkpoints only after the destination operation is confirmed.
- Reconcile existing destination objects before replaying writes.
- Surface partial completion and an explicit retry/resume path.
- Keep user-visible logs without exposing authentication secrets.
For repeated copies, avoid enumerating the entire drive every time. Where applicable, Microsoft Graph delta queries can track changes and reduce unnecessary polling. Your implementation must still handle deleted items, invalidated state, permissions, pagination, and eventual consistency.
4. Do not confuse a live mirror with recoverable backup
If a one-way mirror replicates accidental deletion, you have two copies of the same mistake. A recovery design should ask whether the destination is separately accessible, whether it retains versions, whether deletion propagation is appropriate, and whether restores have been tested.
When OneDrive itself is inaccessible, a new API-driven copy may be impossible. The best outage-time option is usually a second copy that already exists in another provider or an offline store.
5. A practical service for cloud-to-cloud copies: RiceDrive
Not every team needs to build and maintain its own migration worker. RiceDrive is a cloud-to-cloud transfer product that lets users connect OneDrive to destinations such as Google Drive, Dropbox, MEGA, Box, pCloud, and selected object stores—without a manual local download/upload cycle.
The product supports 40+ cloud platforms and protocols. Available workflows include background tasks, transfer logs, filters, and scheduled transfers; the free tier includes 10GB of monthly transfer traffic.
A useful first workflow is OneDrive → a separate destination account, using one-way copy settings, a limited test folder, and post-transfer verification. Work or school accounts may require administrative approval, and file-sharing links and version history should not be assumed to migrate unchanged.
See the illustrated OneDrive backup and transfer guide for setup steps and provider considerations.
This is a product-level backup option, not a claim that RiceDrive internally implements every architectural pattern in the diagram above. Nor can RiceDrive read OneDrive files through an unavailable Microsoft API. Set up and validate the independent copy while both providers are operating normally.
6. An incident-readiness checklist for teams
Before the next outage:
- Define an RPO (acceptable data age) and RTO (acceptable recovery time).
- Alert on provider-level failures, not only internal worker exceptions.
- Make transfer state durable and retries bounded.
- Keep a separately accessible destination with appropriate retention.
- Test opening and restoring representative files, not only successful API responses.
Bottom line: Availability incidents will happen. The engineering goal is to make a temporary upstream failure visible, recoverable, and less disruptive to users—not to pretend that another API client can repair an unavailable source.
References: Microsoft Service Health · Hitotsubashi University outage report · Microsoft Graph throttling · Microsoft Graph delta queries.
Disclosure: This article is published by the RiceDrive team. RiceDrive is mentioned as one option for cloud-to-cloud transfers.
