Cloudflare’s global network outage is steadily improving after several hours of instability that affected millions of websites, APIs, authentication systems, and the company’s consumer and enterprise connectivity services. Following a series of investigative updates, Cloudflare has now restored key functionality—including Access and WARP—and is progressing with recovery across the rest of its services.

As of 13:35 UTC, Cloudflare engineers report that they are actively restoring service for application service customers, and error rates for WARP and Access have returned to pre-incident levels.

🟢 13:35 UTC — Recovery Progress Continues

“We are continuing working on restoring service for application services customers.”

Cloudflare’s application-layer services (including web, API, and edge functions) are now undergoing restoration. This suggests that core infrastructure components are stabilizing.

🟢 13:13 UTC — Cloudflare Access & WARP Fully Recovered

This is one of the biggest positive updates so far:

“We have made changes that have allowed Cloudflare Access and WARP to recover. Error levels for Access and WARP users have returned to pre-incident rates.
We have re-enabled WARP access in London.”

Earlier in the day, London WARP access had been intentionally disabled as Cloudflare isolated problematic routes. The re-enabling indicates that the network is stabilizing and that emergency isolation steps are no longer necessary.

Access (Cloudflare’s Zero Trust identity-based gateway) returning to normal is also a strong sign that internal service networks were successfully patched.

🟡 13:09 UTC — Issue Identified and Fix Implemented

This was the turning point of the entire incident:

“The issue has been identified and a fix is being implemented.”

After nearly 90 minutes of continuous investigation, Cloudflare pinpointed the exact cause. Although no technical details have been made public yet, the implementation of the fix marked the beginning of system-wide recovery.

🟡 13:04 UTC — WARP Disabled in London (Now Resolved)

During remediation attempts, Cloudflare temporarily shut down WARP in London:

“We have disabled WARP access in London. Users in London trying to access the Internet via WARP will see a failure to connect.”

This was reversed at 13:13 UTC, when WARP was re-enabled.

🟠 12:53 UTC & 12:37 UTC — Continued Investigation

“We are continuing to investigate this issue.”

These updates indicated that Cloudflare had not yet isolated the underlying problem.

🟠 12:21 UTC — Partial Recovery Observed

“We are seeing services recover, but customers may continue to observe higher-than-normal error rates.”

Some services started to show early signs of stabilization.

🟠 12:03 UTC — Investigation Continues

“We are continuing to investigate this issue.”

🔴 11:48 UTC — Initial Incident Alert

Cloudflare began the incident timeline with:

“Cloudflare is experiencing an internal service degradation. Some services may be intermittently impacted.”

The outage was classified as internal, meaning the issue originated from Cloudflare’s own systems—not external routing providers.

🌍 What Was Impacted During the Outage?

Given Cloudflare’s global footprint, the outage disrupted multiple services:

Cloudflare Access (Zero Trust login)

• Authentication failures
• Unreachable internal apps
• Delayed policy enforcement

Cloudflare WARP (consumer & enterprise VPN)

• Complete failure in London
• Degraded connectivity in other regions

Web & API Traffic

• Widespread 500 errors
• Latency increases
• Unstable routing

Cloudflare Dashboard

• Slow/stuck login
• Unresponsive analytics
• Configuration delays

Cloudflare API

• Failing requests
• Broken automation workflows

Workers / Pages

• Deployment errors
• Delayed or failed script execution

🧠 Why the Outage Was Significant

1. Global impact across multiple service layers

From CDN to Zero Trust, numerous Cloudflare products were affected at once.

2. Internal service degradation

This indicates that a core internal system malfunctioned, likely cascading across global PoPs.

3. Temporary regional service shutdowns

Disabling WARP in London is extremely rare, showing the seriousness of the instability.

4. Slow recovery propagation

Even after identifying the issue, Cloudflare needed time to stabilize multiple services.

🔧 What Happens Next?

Cloudflare will now:

• Continue restoring application-level services
• Monitor system stability across all data centers
• Reduce residual error rates
• Publish additional updates as recovery progresses
• Release a full post-incident analysis (typically within days)

Cloudflare may also temporarily throttle or isolate specific regions if new instabilities arise during recovery.

📌 Conclusion

After hours of global disruption, Cloudflare has made significant progress in resolving the outage. With the root cause identified and a fix implemented, Cloudflare Access and WARP have returned to normal operation, including the restoration of WARP in London. Work is ongoing to bring remaining application services back to full stability.

This incident highlights both the scale of Cloudflare’s infrastructure and how deeply interconnected the modern internet is with the company’s global network.

More updates from Cloudflare are expected throughout the day as full recovery continues.