Microsoft 365 outage: what happened and what UK businesses should do

Are Microsoft having issues today?

Reuters reported continuing disruption on Friday morning, with Microsoft describing server problems and early signs of stabilisation. That is evidence of a significant incident, but it does not mean every feature failed for every customer. Read the dated Reuters incident report alongside the latest provider information.

For a business, the useful question is narrower than whether Microsoft is down: can our people complete the activities we need today? Record failed actions, affected users and the last successful attempt. That gives your support team something more useful than a collection of screenshots with no times or context.

What do we know about the Microsoft outage so far?

The reporting reviewed describes an incident involving Exchange Online and Microsoft 365 functions that depend on email services. Reuters also reported that Microsoft had not identified evidence of malicious activity at that stage. Neither statement establishes a final root cause or guarantees that every customer has recovered.

Keep three categories separate: confirmed provider updates, symptoms observed in your business and explanations still being investigated. Mixing these together creates misleading staff messages. A successful test by one colleague is useful evidence about that account, not proof that shared mailboxes, file access and automated jobs are healthy.

Why is Microsoft down today?

The full explanation needs Microsoft’s completed investigation. Early reporting points to problems in the infrastructure supporting the affected services, but a recovery action is not automatically the root cause. Adding capacity, restarting equipment or changing how requests are handled can be mitigation steps while engineers investigate the trigger.

For managers, distinguish the trigger, the failure mechanism and the resulting business interruption. A trigger might start an incident; the mechanism explains why it spread or persisted; the interruption describes what customers could not do. A useful final report addresses all three, plus the safeguards intended to reduce recurrence.

Do not publish a confident claim that this was a cyber attack, an expired certificate or a faulty update without appropriate evidence. Similarly, the absence of an announced attack does not replace your normal security monitoring. Treat technical theories as theories until the responsible provider confirms the findings.

Is the Microsoft outage still ongoing?

Check at the time you need to make a decision. A morning news report cannot establish the position later that afternoon. Your IT team should record the advisory’s most recent update and compare it with a small set of practical tests, including the workflows your business actually relies on.

Use Microsoft’s public service-status page when appropriate, particularly if the admin centre cannot be reached. For business accounts, the tenant’s Service health view can provide more relevant detail. A quiet public status page does not prove that a particular mailbox, tenant or integration has no problem.

During recovery, tell staff what has been tested rather than announcing that everything is fixed. For example: internal email is working for the sample accounts, external delivery is being checked and shared mailbox access remains under review. Set the next update time even if there is no new provider estimate.

Why is Microsoft not working for me when colleagues can sign in?

A shared incident can affect people differently, while an unrelated local fault can happen at the same time. Compare the same task across a few authorised accounts and supported devices. Note whether the problem occurs in the desktop application, browser or both. Avoid asking everyone to conduct repeated experiments independently.

For initial triage, your support team can check these patterns:

• One device: investigate its connection, application state and recent changes.
• One user: review the account and the specific action that fails.
• One site: assess local connectivity alongside provider status.
• Several sites or accounts: compare the symptoms with a wider advisory.

These are investigation prompts, not diagnoses. An error message saying that a server is unavailable does not establish who owns the fault. Preserve the wording and time, then let the helpdesk assess it. Our remote IT support service is relevant where a local issue needs investigation alongside a provider incident.

Which Microsoft services and business processes could be affected?

Start with the task rather than the product logo. A team might still open a chat while failing to retrieve a calendar item or complete a document approval. Your impact assessment should distinguish the provider’s affected-service list from your own tested results. Do not assume the whole Microsoft portfolio is unavailable.

Someone should own each critical process. Otherwise, staff may wait for an email recovery while an order-import backlog grows unnoticed. Teams using SharePoint or connected business systems should test the complete handover between applications before declaring recovery.

What should businesses do in the first 30 minutes?

1. Appoint an incident coordinator. Give staff one route for updates and reports.
2. Confirm the scope. Sample affected users and tasks, then check the applicable service advisory.
3. Identify urgent commitments. List customer deadlines, essential operations and decisions that cannot wait.
4. Choose approved alternatives. Confirm the communication channel and where temporary records belong.
5. Pause unrelated changes. Keep a record of any necessary intervention and its owner.
6. Set the next update. Give a time, even when restoration remains uncertain.

The aim is controlled continuity, not frantic troubleshooting. Separate the person handling provider information from the manager deciding business priorities where staffing allows. A short incident log should record what happened, decisions made and outstanding risks. It becomes the basis for recovery checks and the later review.

Make the first instruction easy to act on. Tell people how to report an urgent requirement and what not to change. Link them to one approved update location rather than asking them to monitor several social feeds and repeat unverified fixes.

Should you reinstall Outlook, reset passwords or change DNS?

Not as a blanket response to a confirmed provider incident. Those changes need a reason connected to the evidence. Rebuilding an application profile may complicate access to locally available information; changing mail routing can introduce another problem while the original service is recovering. Ask your administrator before making changes.

A local issue may still require repair, and a genuine account-security concern may still require immediate action. The important distinction is whether the proposed step addresses that specific problem. Record who approved it, what changed and how it can be reversed. Avoid mixing unrelated improvements into the response.

Never weaken multifactor authentication or security controls simply to make a timeout disappear. A malicious sign-in, suspicious payment request or unrecognised device needs its own security assessment. An outage announcement should not become a reason to overlook evidence of a separate incident.

Can staff keep working while Outlook or Microsoft 365 is unavailable?

Some work may continue using information already available on approved devices. Microsoft documents offline capabilities for Outlook, but availability depends on the application version, configuration and data already stored locally. A cached message can help with reference work; it is not proof that a new message has been delivered.

For documents, agree who edits the temporary copy and where it is saved. Keep client and employee information within approved devices and locations. If two people create separate versions of a spreadsheet, record the owner responsible for reconciling them. Otherwise, the workaround becomes a second operational problem after restoration.

Plan useful work that does not need the failed dependency: prepare drafts, review available records or organise follow-up tasks. Do not move confidential files into personal email or consumer storage just because those services load. Review the limits described in Microsoft’s Outlook offline guidance.

How should you communicate with customers and staff?

Use an approved channel that remains available and is appropriate for the information involved. A business telephone number or public website notice may be useful for general updates. Do not assume that the affected email platform can reliably distribute the outage instructions. Keep emergency contact information available through an authorised alternative.

A customer notice should describe the practical impact, offer an alternative contact route and say when the next update is expected. Avoid promising a restoration time borrowed from an unverified post. If only email responses are delayed, say that; do not imply that every service your business provides has stopped.

Adapt that wording to your actual experience. Someone must own removing or updating the notice when the impact changes.

What does the outage mean for finance, manufacturing and professional firms?

Priorities differ between organisations. Finance teams may need to confirm whether an approval or payment instruction was received. Manufacturers may need an alternative route for urgent supplier information. Professional firms may need to document attempts to communicate about a deadline. These are planning scenarios, not claims that every such activity failed in this incident.

Rank activities by their business consequence and the time available. Record the person authorised to approve an exception, the temporary process and how decisions will return to the normal system. Keeping a service running is not enough if the organisation loses the evidence of who authorised the work.

For regulated, client-sensitive or safety-related activity, use the organisation’s existing escalation process and obtain appropriate professional advice where needed. An availability problem does not automatically establish a data breach or a missed legal obligation. The actual facts and applicable responsibilities determine the response.

Could criminals exploit a Microsoft outage?

Yes, an outage creates an opportunity for plausible impersonation. Staff expecting a fix may be more receptive to an unsolicited support call or message. That is a risk to prepare for, not evidence that a particular scam has reached your organisation or that criminals caused the original disruption.

Tell staff to use established support contact details rather than numbers supplied in an unexpected message. They should not disclose passwords, approve unfamiliar authentication prompts or install a remote-access tool at a caller’s request. A familiar logo or knowledge of the outage does not authenticate the person contacting them.

Keep payment verification in place if normal communications are disrupted. Confirm unusual instructions through a known authorised contact route. Businesses reviewing their wider response can use our cyber incident response planning guide and discuss responsibilities through managed security services.

What should you check when Microsoft services return?

Recovery needs business tests as well as a provider status change. Start with a representative set of users and critical workflows. Test internal and external communications, required shared mailboxes, file access and essential connected applications. Record results before asking everyone to resume delayed work simultaneously.

• Check important outgoing messages and the status of urgent correspondence.
• Review local document copies and reconcile competing versions.
• Identify failed or delayed automations before replaying them.
• Confirm whether manual orders, approvals or records need entering.
• Look for duplicate work before resubmitting a transaction.
• Remove temporary notices and brief staff on remaining exceptions.

A failed automation may have completed part of its work before stopping. Its owner should establish what happened before restarting it. For example, a customer record might exist even if the notification failed. Controlled reconciliation is more useful than assuming every failed job should simply run again.

Would backups or a second internet connection prevent this?

Different safeguards solve different problems. A second connection can help when your own connectivity fails; it cannot guarantee availability of an affected provider platform. Backups address recovery of protected information according to their scope. They do not automatically supply replacement email, identity, collaboration and application services.

Ask what the business needs to do during a loss of availability and for how long. Access to an approved reference document may be sufficient for one activity. Another may require a separately tested communication route or a controlled manual process. Buy and test against those requirements rather than a vague promise of resilience.

Our business continuity plan template helps structure that discussion. The practical test is whether the people involved can use the agreed fallback safely when the normal tools are unavailable.

What should your IT provider do during a Microsoft outage?

Your provider should establish scope, follow applicable advisories, communicate the business impact and investigate separate local faults. It should help you use approved alternatives, preserve useful evidence and test recovery. It cannot credibly promise to repair Microsoft’s underlying infrastructure or guarantee a restoration time it does not control.

Afterwards, ask for a review covering the interruption, workarounds, communication gaps and outstanding changes. Assign each improvement an owner and a reason. A useful managed IT support relationship makes those responsibilities clear before the next incident.

How can you test whether your continuity plan would actually work?

Run a short exercise around a realistic loss of access. Ask the team to imagine that email and shared cloud files are unavailable for half a working day. Give them a customer request, a supplier query and a document deadline. Observe where they obtain contact details, who makes decisions and how they record the work.

The exercise should use test information and agreed boundaries. Do not interrupt production systems or send real customer communications merely to demonstrate the scenario. You can learn a great deal by walking through the steps and checking whether the required instructions are accessible.

Ask practical questions. Is the emergency telephone list trapped inside the unavailable platform? Does the nominated deputy know the process? Can a remote worker access the approved fallback? Who reconciles the temporary spreadsheet afterwards? A plan that names a tool without explaining access and ownership is difficult to use under pressure.

Record a small set of improvements and test those again after completion. The useful outcome is a demonstrated ability to complete essential activities, with clear limits. A long document that nobody can retrieve during an outage provides little immediate assistance.

What should directors review after this incident?

Review the difference between the interruption you expected and the interruption you experienced. Which customer commitments became difficult? Which decisions waited for one person? Which workarounds were useful, and which introduced duplicate records or uncertainty? Include operational staff in the discussion so the findings reflect how work actually happens.

Measure the consequence where records support it: delayed tasks, staff time spent coordinating, missed communications and the backlog remaining after restoration. Distinguish measured figures from estimates. This gives the business a better basis for deciding whether a proposed improvement is proportionate.

Review supplier dependencies across the complete workflow. A separate application may still depend on Microsoft email for notifications or account recovery. Independence should be tested at the activity level rather than inferred from different brand names on a software inventory.

Finally, decide who owns the incident playbook and when it will be reviewed again. Changes to staff, applications and working locations can make an earlier plan less useful. Build the review into normal service discussions instead of waiting until the next interruption exposes the same gap.

Where should you check for the next update?

Use the latest applicable Microsoft service advisory and your IT team’s tested findings. Microsoft’s Service health documentation explains where administrators can view incidents, update history and the distinction between an advisory and an interruption.

Keep the date attached when sharing this article. It explains the reporting reviewed on 13 November 2026 and practical preparation; it should not be reused unchanged as proof that Microsoft is down on a later day. Update the incident summary when verified recovery information and the final investigation become available.