Azure Front Door Outage 2025: How a Config Error Crippled Xbox Live and Azure Portal

Microsoft’s cloud backbone faltered on October 29, 2025, when a configuration error in Azure Front Door — Microsoft’s global edge and routing fabric — precipitated a broad Microsoft Azure outage that knocked Xbox Live, Minecraft authentication, Microsoft 365 admin portals and a raft of customer websites offline for hours as engineers rolled back the offending config and rerouted traffic to healthy nodes.

Background / Overview​

Azure Front Door (AFD) is a global, Layer‑7 edge service that performs TLS termination, global HTTP(S) load balancing, Web Application Firewall (WAF) enforcement, DNS-level routing and origin failover for both Microsoft’s first‑party services and thousands of customer workloads. When AFD’s control plane or routing rules fail, the observable symptoms are immediate and wide‑ranging: failed sign‑ins, blank admin blades, 502/504 gateway errors and stalled game authentication flows.
On the afternoon of October 29, 2025 (beginning at roughly 16:00 UTC), monitoring systems detected packet loss and routing anomalies that traced back to a configuration change inside Azure’s edge fabric. Microsoft identified the change as "inadvertent," froze further AFD updates, and began deploying a rollback to a last‑known‑good configuration while failing the Azure Portal away from Front Door to restore management access. The outage’s visible consumer impact was unmistakable: Xbox sign‑ins failed, Game Pass and storefront operations stalled, and Minecraft multiplayer and realm access suffered authentication timeouts. At the same time, Microsoft 365 admin consoles and the Azure Portal experienced blank or partially rendered blades, complicating remediation for IT admins. Downdetector style trackers recorded tens of thousands of user reports at peak.

---

What exactly failed: Azure Front Door, DNS and control‑plane risk​

Azure Front Door’s role explained​

AFD sits at the intersection of routing, security and identity for many public endpoints. It:

• Terminates TLS at edge Points of Presence (PoPs).
• Makes global routing decisions and performs origin failover.
• Enforces WAF and ACL rules at the edge.
• Fronts identity token exchanges for Entra ID (Azure AD) in many scenarios.

Those combined responsibilities make AFD a high‑blast‑radius component: a single misapplied rule or a control‑plane regression can cause DNS or TLS anomalies that prevent clients from finding or authenticating to services, even when backend compute is healthy.

The proximate trigger and the mechanics of propagation​

Microsoft’s operational messages and independent network telemetry converged on the same narrative: an inadvertent configuration change propagated through AFD’s global control plane, producing DNS and routing abnormalities and causing a measurable loss of capacity at a subset of frontends. That, in turn, produced authentication timeouts (Entra token issuance failures), blank admin blades and 502/504 responses for apps fronted by AFD. Microsoft halted further Front Door changes, deployed a rollback, and rerouted traffic to healthy PoPs while recovering nodes. This failure mode — a control‑plane configuration mistake that cascades through global DNS/routing — is painful precisely because it affects both Microsoft’s consumer products (Xbox, Minecraft) and enterprise control planes (Azure Portal, Microsoft 365 admin center) simultaneously.

---

Timeline of the incident (concise)​

• Detection (~16:00 UTC, October 29, 2025) — Internal telemetry and external monitors detected packet loss and routing errors at AFD frontends; user reports spiked.
• Public acknowledgement — Microsoft posted incident advisories attributing the issue to AFD and noting an inadvertent configuration change; they froze AFD configuration changes.
• Mitigation — Engineers initiated a rollback to the “last known good” configuration, failed the Azure Portal away from AFD to restore management access, restarted orchestration units where needed, and rebalanced traffic to healthy nodes.
• Initial recovery signs — Microsoft announced the last‑known‑good deployment completed and reported progressive restoration while continuing node recovery and routing convergence. Some customers still experienced intermittent issues after initial recovery.

Note: public reports and outage trackers placed the peak number of user‑reported incidents in the tens of thousands during the worst window; such aggregator figures are useful signals but are noisy and should be treated as indicative rather than exact.

---

Immediate impact: gaming, enterprise portals and downstream services​

Xbox, Game Pass and Minecraft​

Because Xbox Live and Minecraft authentication flows rely on Microsoft’s central identity surfaces and AFD routing, players saw:

• Failed sign‑ins and repeated authentication prompts.
• Stalled downloads and blocked storefront access.
• Multiplayer and realm connectivity interruptions for Minecraft realms and hosted sessions.

Single‑player or offline modes often remained playable, but any flow requiring Entra/Xbox token issuance could be impacted until routing and token issuance stabilized. Microsoft’s status updates and community reports confirmed those symptoms.

Microsoft 365 and Azure Portal​

Administrators reported blank or partially rendered blades in the Azure Portal and Microsoft 365 admin center, limiting their ability to act via the GUI. Microsoft suggested programmatic fallbacks (PowerShell, CLI) for urgent admin tasks while the portal failover and recovery proceeded. Failing the portal away from AFD allowed many customers to regain portal sign‑in even while broader AFD customer traffic remained inconsistent.

Downstream corporate/customer impacts​

Because many third‑party sites front their public endpoints through AFD, the outage surfaced as 502/504 errors or complete unreachability for external customers. Reports included impacts at airlines, retailers and some banking or payment endpoints; early media coverage named several affected brands, though corporate confirmations varied and some claims remain unverified pending statements from the affected companies.

---

Why this outage is meaningful: systemic architecture and business risk​

Concentration of critical functions​

Modern hyperscaler architectures centralize essential functions — global routing, TLS termination and identity — into a small set of shared services for efficiency and manageability. That centralization reduces operational overhead but creates single‑point multipliers where one control‑plane fault affects many downstream, otherwise independent, services.
This incident underscores a foundational truth: convenience at scale brings concentrated risk. When authentication and edge routing are shared, authentication timing, DNS resolution and edge capacity become systemic dependencies rather than isolated features.

Change control and validation gaps​

Amoeba‑like or rapid changes to distributed control planes require rigorous pre‑deployment validation, canarying, and automated rollback triggers. The fact that Microsoft attributed the outage to an inadvertent configuration change suggests either a gap in pre‑validation, an unexpected interaction in the control plane, or a failure in the rollout safeguards that prevent a bad configuration from global propagation. These are precisely the operational areas cloud providers continuously iterate on after high‑impact incidents.

Commercial and reputational consequences​

For enterprises, hours of portal inaccessibility or failed authentication can translate into lost revenue, missed SLAs, and support overhead. For Microsoft, high‑visibility outages touching consumer gaming products and enterprise portals simultaneously increase scrutiny on operational practices and heighten customer pressure for improved transparency and tougher safety nets.

---

What Microsoft did well — containment and recovery strengths​

• Rapid containment playbook: Microsoft immediately blocked further AFD changes, a textbook "stop the bleeding" action that prevents further propagation of a bad config.
• Last‑known‑good rollback: Deploying a rollback and recovering to a previously validated configuration is an effective mitigation for control‑plane misconfigurations. Microsoft reported this deployment completed and observed initial recovery signs.
• Failover for management plane: Steering the Azure Portal off Front Door restored management access for many admins, reducing remediation friction for enterprise responders.
• Transparent, iterative updates: Microsoft posted rolling status updates and advised programmatic workarounds to reduce the impact on admins attempting urgent actions.

---

Remaining weaknesses and operational lessons​

Residual fragility in centralized controls​

Even with a successful rollback, the incident highlights the fragility that remains when core functions are shared. Residual, tenant‑specific edge state, DNS caches and ISP routing differences meant some customers continued to see intermittent errors after the global rollback. These sticking points are precisely the friction that makes recovery messy and drawn‑out.

Change‑validation and automated safety nets​

The outage suggests more investment is required in deployment safety: stronger canary isolation, programmable circuit breakers, and real‑time validation logic that can detect protocol‑level anomalies before a change reaches global PoPs. Microsoft and other hyperscalers have addressed similar needs before; this event should accelerate further hardening.

Communication and third‑party impact accountability​

When a cloud provider’s control plane disrupts third‑party customers, the downstream damage includes lost transactions and degraded customer trust. Greater visibility into which services and customers are fronted by shared fabrics — and clearer operational SLAs covering control‑plane events — would help enterprise buyers evaluate and mitigate vendor concentration risk.

---

Practical guidance: what admins, developers and gamers should do now​

For IT administrators and SREs​

• Map your dependencies — explicitly document which public endpoints, admin portals and identity flows transit AFD or other managed edge services.
• Implement programmatic fallbacks — prepare and test PowerShell/CLI, API and service principal flows for management plane tasks when portals are unavailable.
• Adopt DNS and routing resilience — configure reliable TTLs, multiple failover paths (Azure Traffic Manager or other traffic‑manager services), and health probes that detect edge anomalies early.
• Run incident drills — rehearse an AFD/edge outage scenario, including rollbacks and cross‑team playbooks, to reduce recovery time in a real event.

For developers and SaaS vendors on Azure​

• Use multi‑fronting strategies where feasible: front your app with multiple ingress options (AFD + Traffic Manager + direct origin failover) so a single fronting fabric is not a critical choke point.
• Cache resiliently: design for cache‑first experience for non‑interactive flows where possible, reducing reliance on origin traffic during edge faults.

For gamers and consumers​

• Expect intermittent authentication issues during control‑plane outages; offline modes and single‑player play are often unaffected.
• Follow official service status channels; Microsoft’s status updates provide real‑time mitigation guidance and ETAs for recovery.

---

Broader industry context: concentration risk and vendor diversification​

October 2025 saw multiple high‑profile hyperscaler incidents in close succession. Those back‑to‑back outages renewed debate about the systemic risk created by heavy dependence on a handful of cloud providers. Enterprises must reconcile the obvious operational and economic advantages of hyperscalers with the non‑trivial risk that a single control‑plane failure can cascade across business lines and consumer experiences. Diversification strategies — multi‑cloud, hybrid architectures, and well‑tested fallbacks — are costly, but they reduce blast radius and offer operational options when a single provider’s control plane is impaired.

---

What we still don’t know — and what to watch for in Microsoft’s post‑incident report​

• The exact configuration change that triggered propagation remains a technical detail Microsoft typically expands on in a formal post‑incident review. Until that report is published, specific assertions about patch semantics or root code defects should be treated cautiously.
• Concrete metrics on capacity loss (e.g., percentage of AFD frontends affected) vary between observability vendors and Microsoft’s internal telemetry; expect a later, reconciled figure in the public post‑mortem.
• Whether Microsoft will implement structural changes beyond process hardening — such as architectural segmentation to reduce AFD’s blast radius — is a strategic decision that may take months and significant product investment.

Flag: any claim about precise capacity loss numbers, ISP‑specific causation, or the full roster of third‑party sites impacted should be treated as provisional until Microsoft’s detailed post‑incident analysis is released and verified by independent telemetry.

---

The bottom line​

The October 29, 2025 Azure outage is a textbook example of how shared control planes in modern cloud platforms can amplify a single change into a global disruption. Microsoft’s containment steps — freezing changes, rolling back to a last‑known‑good configuration, rerouting the portal, and recovering nodes — were appropriate and effective in restoring most traffic. Yet the incident makes plain that convenience and scale come with architectural tradeoffs that enterprises must manage proactively.
For system architects and IT leaders, the practical takeaway is immediate: audit your cloud dependency map, validate programmatic management paths, and rehearse failover scenarios that assume the edge and identity layers can fail independently of backend compute. For cloud providers, the imperative is equally clear: safer, more constrained deployment pipelines, better canary isolation and visible guarantees for control‑plane robustness must remain a top priority.
Microsoft’s status messages indicate a largely successful mitigation was deployed and that services were progressively recovering, but pockets of instability and residual effects persisted for some customers during the recovery window — underscoring that even a repaired configuration can take time to converge across cached DNS, ISP routing and session state.

---

Quick summary for readers who want the headline facts​

• What happened: An inadvertent configuration change in Azure Front Door caused DNS/routing anomalies and a capacity loss at a subset of edge PoPs on October 29, 2025.
• Services impacted: Xbox Live, Minecraft authentication and multiplayer flows, Microsoft 365 admin centers, the Azure Portal, and many third‑party sites fronted by AFD experienced outages or degraded availability.
• Microsoft’s response: Blocked further AFD changes, deployed a last‑known‑good rollback, failed the Azure Portal away from AFD to restore management access, and recovered nodes while rebalancing traffic.
• Recovery status: Initial fix deployment showed signs of recovery; services were progressively restored though some users experienced intermittent issues as routing and caches converged.

---

This episode is a reminder that in a world increasingly powered by cloud fabric, operational discipline, diversified fallbacks and transparent post‑incident accountability are not optional extras — they are core controls for modern digital resilience.

---

Source: Happy Mag Microsoft Azure outage Knocks Xbox and Minecraft offline, here's the latest update

 

[ChatGPT]

Microsoft’s global cloud fabric stumbled on October 29, 2025, when a configuration error in Azure Front Door triggered DNS and routing failures that knocked Microsoft 365 (Office 365), Xbox Live and Minecraft sign‑in systems, the Azure Portal and thousands of downstream customer sites offline — an incident that produced a visible spike in outage reports and forced Microsoft to roll back a problematic change while failing management traffic away from the affected edge.

---

Background / Overview​

Microsoft Azure operates a global edge and application delivery fabric called Azure Front Door (AFD). AFD performs Layer‑7 routing, TLS termination, Web Application Firewall (WAF) enforcement and DNS-level routing for many Microsoft first‑party services and thousands of customer workloads. Because it sits in front of identity services and management portals, a control‑plane fault there can look like a broad platform outage even when origin servers are healthy. Microsoft’s status updates and multiple independent reports identified an inadvertent configuration change in AFD as the proximate trigger for the disruption. This was not an isolated consumer inconvenience: the outage produced real‑world operational impacts for airlines, retail chains and gaming ecosystems, and arrived just days after a separate major outage at another hyperscaler — underscoring systemic fragility in an economy built on a small set of cloud control planes.

---

What happened — the technical anatomy​

Azure Front Door: the “front door” for modern web services​

Azure Front Door acts as a globally distributed Layer‑7 ingress fabric. Its responsibilities include:

• TLS termination and certificate binding at edge points of presence (PoPs).
• Global HTTP(S) routing and anycast-based traffic steering.
• DNS‑level mapping and host header resolution for fronted services.
• WAF enforcement, origin selection and request routing.

Because AFD is in the client handshake path and often fronts identity issuance (Microsoft Entra ID / Azure AD), any control‑plane misconfiguration can prevent clients from locating services, completing TLS handshakes or obtaining authentication tokens — symptoms indistinguishable from a platform outage.

The proximate trigger and symptoms​

Microsoft’s incident communications said a configuration change propagated through a portion of AFD’s control plane and produced DNS and routing anomalies starting at approximately 16:00 UTC on October 29, 2025. The visible effects included:

• Authentication failures and blank admin blades in the Azure Portal and Microsoft 365 admin center.
• Sign‑in and matchmaking failures for Xbox Live and Minecraft.
• 502/504 gateway errors, DNS resolution failures and timeouts for thousands of third‑party sites that use AFD for public ingress.

Microsoft blocked further AFD changes, deployed a rollback to a last‑known‑good configuration, and failed the Azure Portal away from AFD to restore management access while nodes were recovered and traffic rebalanced. Initial mitigation produced progressive recovery over the following hours.

---

Timeline (concise, verifiable)​

• Detection — ~16:00 UTC, Oct 29, 2025: internal telemetry and external monitors detect elevated latencies, DNS anomalies and HTTP gateway failures for AFD‑fronted endpoints. Public outage trackers spike.
• Acknowledgement — Microsoft posts incident advisories naming Azure Front Door and suspects an inadvertent configuration change.
• Containment — Engineers block further AFD configuration rollouts and initiate a rollback to a validated prior state; Azure Portal traffic is failed away from AFD where possible.
• Recovery — Rollback completes; Microsoft reports initial signs of recovery while continuing to recover nodes and monitor DNS convergence. Residual, tenant‑specific failures persist due to DNS TTLs and global cache convergence.

---

Services and sectors affected​

The outage’s blast radius was broad because AFD fronts both Microsoft’s own services and thousands of customer sites. A non‑exhaustive list of visible impacts:

• Microsoft 365 / Office 365: sign‑in failures, blank admin blades and intermittent web app access.
• Xbox Live / Microsoft Store / Game Pass: authentication, storefront, download and multiplayer disruptions.
• Minecraft authentication and Realms matchmaking: launcher failures and sign‑in timeouts.
• Airlines: check‑in, mobile apps and boarding‑pass issuance degraded (Alaska Airlines, JetBlue and others reported problems).
• Retail and consumer apps: outages or intermittent failures reported at Starbucks, Costco, Kroger and other chains that rely on Azure‑fronted endpoints.
• Launch‑sensitive game releases and digital storefront operations: multiple game purchases and installs were disrupted during the outage window.

The real‑world footprint — airports, point‑of‑sale systems and loyalty app interruptions — demonstrates how a cloud edge failure cascades into physical operations for organizations that rely on internet‑facing services.

---

Numbers, trackers and why the counts differ​

Crowd‑sourced outage trackers showed large spikes in user reports, but the headline numbers varied across outlets. Sky News cited Downdetector posts that showed over 105,000 reports for Azure at peak, while other reporting (including Reuters and regional outlets) published lower—but still large—figures (for example, ~16,600 reports in some Downdetector snapshots). These differences are expected: outage aggregators sample different feeds and timestamps and report instantaneous snapshots rather than authoritative telemetry from the vendor. Treat aggregator counts as indicative of scale and spread, not as precise per‑tenant impact metrics. Key caveat: Microsoft’s internal telemetry and post‑incident accounting are the definitive record of impacted tenants and durations. Public trackers are invaluable for early visibility but can produce widely varying numerical peaks depending on time window and geographic sampling.

---

Microsoft’s response — what they did and where they could improve​

What Microsoft did right​

• Rapid public acknowledgement: Microsoft posted rolling updates on its Azure status page and social channels, which helped reduce uncertainty while engineers worked remediation streams.
• Conservative containment: Freezing AFD configuration updates and rolling back to a validated prior configuration minimized the risk of repeated failures and limited the blast radius. Failing the Azure Portal away from AFD restored an essential management access path for administrators.

Where shortcomings were visible​

• Control‑plane exposure: Fronting management consoles and identity issuance through the same global edge fabric amplified the outage’s impact; when the edge control plane failed, GUI‑based remediation paths were impaired.
• Communication granularity: Some enterprise customers reported granular gaps — e.g., which regions or tenants were most affected — that only a vendor‑side post‑incident review can clarify. Public status updates are necessary but insufficient for multi‑region enterprise incident coordination.

Microsoft has committed to internal post‑incident reviews and to publishing a Post Incident Review (PIR) with technical findings and remediation steps; that document will be important for enterprise customers evaluating contractual and architectural responses.

---

Technical analysis — why a Front Door configuration change rippled so far​

Control plane vs data plane​

AFD separates a control plane (configuration, routing policies and deployments) from the data plane (edge nodes that carry client traffic). A faulty control‑plane deployment can change behavior across thousands of PoPs nearly simultaneously. Two damaging failure modes arise:

• Routing divergence: inconsistent configurations across PoPs create intermittent availability and DNS inconsistencies.
• Data‑plane capacity loss: malformed settings or host header mismatches can cause edge nodes to drop requests or return gateway errors at scale.

DNS behavior and the “long tail”​

Even after a rollback, global recovery is slowed by DNS TTLs, resolver caches and ISP propagation. Corrected configuration must propagate through global caches; stale DNS responses cause clients to traffic to continue hitting bad routes or to fail to resolve hostnames for minutes to hours after remediation. This creates a visible long tail of residual user complaints even when the core control‑plane state is corrected.

Identity coupling increases blast radius​

Because many Microsoft services — including Microsoft Entra (Azure AD) — depend on AFD‑fronted token issuance paths, a routing or DNS fault prevents token issuance and single sign‑on flows. That coupling turned what might have been a localized DNS problem into a multi‑product outage impacting productivity apps, gaming, and management consoles. Decoupling identity issuance from the primary public edge fabric is non‑trivial but materially reduces systemic risk.

---

Business impact and operational consequences​

The outage exposed three practical business problems:

• Loss of customer-facing revenue paths: retail and hospitality checkouts, digital orders and rewards were disrupted; airlines faced check‑in delays and manual processing. These failures translate directly to lost revenue and reputational damage.
• Launch‑day risk: timed digital launches (games, streaming promotions) are fragile during provider outages. The Outer Worlds 2 launch was materially affected during this event, with storefront and purchase flows disrupted while the outage persisted.
• Operational overhead for IT teams: administrators lost GUI access to critical management consoles and had to pivot to programmatic tools, or to vendor help channels, while incident communications and service health dashboards evolved.

For enterprises using cloud‑first architectures, the practical cost is not only minutes of outage but also the labor of remediation, customer support surges, and potential SLA negotiations. Incident timing — this outage hit on the same day Microsoft was releasing quarterly earnings — also amplifies public scrutiny.

---

Practical guidance for IT teams and Windows administrators​

Short‑term and medium‑term tactical actions every administrator should consider:

• Maintain alternative admin paths
• 1. Ensure programmatic access (Azure CLI, PowerShell, API tokens) is tested and usable if the web portal is unavailable.
• 2. Maintain off‑cloud or out‑of‑band consoles where possible for emergency ops.
• Harden authentication resilience
• Keep emergency break‑glass accounts that aren’t dependent on the same front‑door paths. Validate their token workflows regularly.
• Monitor with independent checks
• Use external uptime probes and multi‑provider availability checks (not only provider‑hosted health pages) to detect real user impact quickly. Build alerts on external SLOs rather than only on provider dashboards.
• Engineer multi‑region and multi‑provider fallbacks where business critical
• Identify systems that require true multi‑provider redundancy (payment gateways, check‑in systems, loyalty checkout). For other workloads, document accepted risk and expected RTO.
• Rehearse incident runbooks
• Practice DNS failover, traffic‑manager redirection and last‑resort origin serving. Exercises reduce recovery time and team confusion during real outages.

---

Recommendations for cloud providers (engineering & policy)​

This outage offers several lessons for hyperscalers and platform architects:

• Safer deployment pipelines: strengthen canary isolation and roll‑forward protections for control‑plane changes; avoid blast‑radius‑wide deployments without staged verification.
• Separation of critical control planes: consider design changes that separate identity issuance and management‑plane access from the same public edge mesh used for customer workloads. This reduces risk of losing GUI‑based remediation paths.
• Faster, clearer operational telemetry: publish richer, tenant‑focused health signals that enterprise teams can consume programmatically to speed incident triage and reduce reliance on public aggregator signals.
• Compensation clarity: ensure SLAs and incident compensation frameworks are predictable and easy for enterprise finance/legal teams to apply after systemic outages. Transparency in PIRs and testable remediation commitments will be essential to rebuild and maintain trust.

---

Broader risks and long‑term implications​

• Concentration risk — The repeated high‑impact outages at different hyperscalers in short succession have sharpened debate about the systemic risks of concentration in a handful of cloud providers. Businesses must weigh convenience against single‑provider fragility.
• Supply‑chain ripple effects — Cloud edge outages cascade into travel, retail, finance and public services quickly. Regulators and large customers are watching how providers handle root cause analysis and remediation commitments.
• Contractual and insurance exposure — Recurrent platform outages increase pressure on contractual frameworks (SLAs) and on cyber / operational insurance markets to define covered losses for cloud provider failures.
• Architectural rethink for critical flows — Organizations that cannot tolerate extended outages will need to rethink core customer flows to include offline modes, cached tokens and multi‑provider redundancy — at a real cost in engineering effort.

Where facts remain tentative: the precise number of impacted users by Downdetector varies by snapshot and outlet; the authoritative count will come from Microsoft’s internal incident accounting and the PIR. Public trackers provide public signal, not an audit of affected tenants.

---

Conclusion​

The October 29 Azure outage is a classic modern‑cloud cautionary tale: a single control‑plane configuration change in a global edge fabric created a large‑scale, cross‑product disruption with real world consequences. Microsoft’s playbook response — freeze changes, rollback, and fail management traffic to an alternate ingress — was textbook and drove progressive recovery. At the same time, the incident exposed architectural coupling (edge + identity + management plane) and the practical limits of DNS propagation and cache convergence when recovering from global routing faults. For Windows administrators, enterprise architects and platform operators the takeaways are actionable: audit your dependencies on edge and identity fabrics, ensure programmatic admin paths exist, maintain independent availability monitoring, rehearse failovers and make pragmatic choices about where multi‑provider or offline modes justify the additional cost. For cloud providers, the incident is a reminder that scale must be paired with stricter control‑plane safety, clearer telemetry and a renewed emphasis on architectural isolation for critical control functions.
The forensic work — Microsoft’s internal post‑incident review and external PIR — will be critical to validate technical root causes, explain the propagation mechanics and outline the remedial engineering steps that will prevent similar events. Until that report is published, enterprises should treat this outage as both a prompt and an opportunity: prompt to harden the most critical systems, and an opportunity to codify how to operate when the cloud’s “front door” is suddenly closed.

---

---

Source: Roch Valley Radio Microsoft outage knocks Office 365 and X-Box Live offline for thousands of users