Cloudflare says a network routing incident affecting traffic to origins hosted on Microsoft Azure was resolved on October 6, 2026. The incident began at 13:34 UTC, moved into monitoring at 14:34 UTC and was marked resolved at 15:33 UTC.
If a site that uses Cloudflare in front of an Azure-hosted origin returned errors during that window, the routing incident is a plausible explanation. If you are still seeing errors after the resolution time, however, you should not assume the same incident is still active. The remaining problem may be local DNS, cached errors, an Azure-side issue, an origin configuration problem or an unrelated Cloudflare event.
Cloudflare Azure routing incident timeline
| Time (UTC) | Status | What Cloudflare reported |
|---|---|---|
| 13:34 | Investigating | Cloudflare reported a network-routing problem involving Microsoft Azure origins. |
| 14:15 | Identified | The company said it was continuing to work on a fix. |
| 14:34 | Monitoring | Cloudflare moved the incident into monitoring for further issues. |
| 15:33 | Resolved | The incident was marked resolved. |
The authoritative source is Cloudflare’s official incident page, which identifies the affected service as Network and describes errors for requests directed to origins hosted on Microsoft Azure.
What actually went wrong?
Cloudflare’s public description was intentionally concise. It said the company was aware of an issue with network routing to Microsoft Azure that caused errors for requests going to origins hosted on Azure.
That wording matters. Cloudflare did not describe a total global Cloudflare shutdown. The issue was tied to the path between Cloudflare and Azure-hosted origins, so impact could vary depending on where a website’s backend was hosted and how traffic reached it.
Who could have been affected?
The most exposed configuration was a website or application that used Cloudflare for edge services while its origin infrastructure lived on Microsoft Azure. A request typically moves through multiple layers:
- The visitor connects to Cloudflare.
- Cloudflare processes the request at its edge.
- If the request requires origin content, Cloudflare connects to the origin server.
- For an Azure-hosted origin, that connection must successfully route toward Microsoft’s infrastructure.
If routing between the Cloudflare network and the Azure origin fails or becomes unstable, users can see errors even while the Cloudflare edge itself remains reachable.
What errors might users have seen?
The exact error depends on the application and where the request failed. Possible symptoms can include:
- Pages intermittently failing to load.
- Origin connection errors.
- API requests returning server or gateway errors.
- Static cached content working while dynamic pages fail.
- Login, checkout or account actions failing even when the homepage loads.
- Different behavior by region or network path.
An error during the incident window does not prove this Cloudflare event caused it. Application logs, Cloudflare analytics and Azure monitoring are the best way to confirm whether failures line up with the reported timing.
Is the Cloudflare Azure routing issue still active?
The specific October 6 network-routing incident was marked resolved at 15:33 UTC. Cloudflare’s status history can include separate maintenance events or unrelated incidents at the same time, so a current problem should be checked independently.
For the latest status, use the Cloudflare Status page and Microsoft’s official Azure status resources. Status pages change quickly, which is why a screenshot or social post from earlier in the day can become outdated.
What to check if your site is still down
If your service continues to return errors after Cloudflare marked the routing incident resolved, work through the stack rather than repeatedly changing settings at random.
1. Check the origin directly
Confirm whether the Azure origin is healthy. If you have a safe direct health endpoint or internal monitoring path that bypasses Cloudflare, compare it with the public hostname.
2. Review Azure health and application metrics
Look for resource saturation, failed deployments, load balancer issues, networking changes, certificate problems or application errors around the same time.
3. Check Cloudflare analytics and logs
Look at the error-rate graph before, during and after 13:34–15:33 UTC. If errors sharply return to baseline after the Cloudflare resolution, that supports the incident as the main cause.
4. Purge only when the evidence points to caching
Do not purge an entire cache merely because an origin route failed. A routing problem is not normally fixed by cache purging. Purge only if stale error responses or incorrect cached content persist after origin connectivity is restored.
5. Verify DNS has not changed
Confirm the origin hostname and DNS targets are still correct, especially if your team was making emergency changes while the incident was active.
6. Test from more than one location
A network-routing problem may not affect every region equally. Compare monitoring probes or test from multiple networks before concluding that the issue is universal.
Should you disable Cloudflare to fix it?
Usually, not as a first response. Disabling a proxy or changing DNS during a live routing event can introduce extra variables and make recovery harder. It can also expose an origin that was designed to accept traffic only through Cloudflare.
If your organization has a documented failover architecture, follow that runbook. Otherwise, wait for authoritative status information and make changes only when you understand their effect.
What site owners can learn from this incident
Even a relatively short routing incident can reveal whether an application has adequate observability and redundancy. Teams using Cloudflare in front of Azure can reduce uncertainty during future events by preparing a few basics:
- Monitor both edge availability and origin availability separately.
- Keep timestamps in UTC in incident dashboards.
- Use synthetic checks from more than one region.
- Track origin latency and connection errors, not only homepage uptime.
- Document safe failover procedures before an outage happens.
- Avoid emergency DNS changes unless they are part of a tested plan.
Cloudflare also reported another resolved issue earlier October 6
Cloudflare’s incident history shows a separate RSA Keyless SSL handshake issue that was marked resolved at 09:06 UTC on October 6. That is distinct from the later Azure routing incident. When diagnosing a timestamp, make sure you are matching the correct status event rather than treating every Cloudflare incident on the same day as one outage.
Frequently asked questions
What time did the Cloudflare Azure issue start?
Cloudflare’s incident page lists the start at 13:34 UTC on October 6, 2026.
What time was it resolved?
The incident was marked resolved at 15:33 UTC.
Was all of Cloudflare down?
No. The official notice described a network-routing issue affecting requests directed to origins hosted on Microsoft Azure.
Why would cached pages work while other pages fail?
Cloudflare can serve some cached content without contacting the origin. Dynamic content, API calls or cache misses may still require a successful connection to the Azure origin.
What should I do if errors continue?
Check the current Cloudflare and Azure status pages, then validate origin health, DNS, application logs and regional behavior before making configuration changes.
Bottom line
The October 6 Cloudflare routing problem affecting Microsoft Azure origins lasted just under two hours and was officially resolved at 15:33 UTC. If your site’s errors occurred inside that window, compare your logs with the incident timeline. If problems continue after it, treat them as a fresh troubleshooting case rather than assuming the resolved incident is still ongoing.
For future outage and service-status explainers, follow the AVARIXO Alerts section.
