In brief
Microsoft was still addressing residual Microsoft 365 disruption in its 00:07 MYT update on 14 November. Exchange Online and dependent features were affected, but core Teams calls and direct SharePoint file access remained functional. Small businesses should check real workflows, use approved fallback channels and reconcile delayed work before resuming normally.
What Microsoft has confirmed
Microsoft's November 2026 outage disrupted email and connected business workflows across regions. At the time of writing, the public Service Health Status page still showed service degradation, rather than a completed recovery.
The incident records distinguish two start times: Exchange Online incident EX1550543 began at 16:17 UTC on 12 November, or 00:17 MYT on 13 November. The broader Microsoft 365 incident MO1550821 was recorded from 18:26 UTC, or 02:26 MYT. These times come from Microsoft's incident records reproduced by the University of Pennsylvania's IT service.
Microsoft's public update at 16:07 UTC on 13 November, or 00:07 MYT on 14 November, said teams were addressing residual impact and checking that service restoration remained stable. Microsoft reported no evidence of malicious activity and said a full post-incident report would follow mitigation. A final root-cause explanation should not be inferred from early troubleshooting theories.
This is a timestamped report, not a live status page. Check Microsoft's Service Health Status and your organisation's admin centre for later updates.
Check the feature, not just the app name
Microsoft's update identified Exchange-dependent features as the main area of impact. A service appearing on the affected list did not mean every function in that service had stopped.
- Exchange Online: mailbox access could fail across web, desktop and mobile connection methods, with delayed email delivery.
- Teams: calendar scheduling, invitations and related features could fail. Microsoft said most core calls, meetings, group chats and channel messages were not impacted.
- SharePoint: some external sharing and Exchange-dependent features could be affected, while direct access to stored files remained functional.
- Copilot: chat responses or access to work data could be affected. Other connected administrative and compliance features were also listed.
- Azure: the public status page displayed no Azure issues detected at the check. This does not establish the health of every customer's workload.
Give essential work an approved fallback
For a small business, the useful question is which customer-facing tasks depend on the affected service. An order system may still accept purchases while its email confirmation, staff alert or approval request is delayed. Treat those as separate checks.
Miracode recommends a short continuity checklist rather than an improvised migration during the incident:
- Assign one person to track official updates and give staff a clear next update time. Keep an approved contact list accessible without the affected service.
- Test a small set of essential journeys: receiving an enquiry, acknowledging an order, contacting a supplier and confirming an appointment. Record which steps succeed.
- Use a pre-agreed alternative for urgent communication, such as a phone call. Confirm the recipient and keep confidential material in approved systems rather than copying it into personal accounts.
- Maintain a controlled work log with a reference number, owner and current status. Before repeating an order, payment instruction or message, check whether the original action completed.
- Keep normal access and data-protection controls in place. Do not weaken security just to make a temporary workaround easier.
Verify recovery before clearing the backlog
A successful sign-in is only the first recovery check. Have a technical owner and a business user confirm that messages can be sent and received, calendar changes appear correctly, and the integrations your team actually uses are processing work.
Review queued messages and failed automation runs before restarting batches. Reconcile work completed by phone or through another approved channel so that recovery does not create duplicate orders, repeated reminders or conflicting appointments.
After service stabilises, record what stopped, which fallback worked and what depended on the same provider. Choose one gap to fix and rehearse the revised process. Backups support recovery, but they do not by themselves keep a cloud-dependent workflow running during an outage.
Our related guide, A Backup Is Not a Recovery Plan: Test the Restore Before You Need It, covers how to turn recovery assumptions into a practical test. The link is included below.
