A Cloudflare-branded error page does not by itself prove a Cloudflare outage. Your request may have reached Cloudflare successfully and then failed while reaching the website's origin server. Start with the hostname, error and feature that failed.
Open the official Cloudflare System Status page. Read active incidents for the relevant service and location. This guide helps you interpret symptoms; it is not a live report that Cloudflare is up or down across its network.
Is one website failing or many?
Test the affected hostname and action again once. Compare a different site only as supporting evidence: two websites can have different origins, rules and dependencies even when both use Cloudflare.
If you operate the site, compare a static page with a request that reaches your application. If only one route fails, collect the application logs and route details. If you are a visitor, report the URL, error and time to the site's operator rather than changing settings you do not control.
Ask another person to test the same URL from another location or permitted network. Regional differences can help narrow the issue. They do not establish whether the cause is Cloudflare, an ISP, a resolver or the origin without additional evidence.
Which Cloudflare service is involved?
Cloudflare provides several different services. A dashboard problem does not necessarily mean traffic through the proxy has stopped, and a recursive resolver issue is different from authoritative DNS for your domain.
| What fails | What to investigate |
|---|---|
| Hostname does not resolve | Resolver, authoritative DNS, records and recent changes. |
| Website returns a proxy error | Error details, origin health and relevant network incident. |
| Worker route fails | Worker logs, deployment and service dependencies. |
| Dashboard or API is unavailable | Management operations separately from serving traffic. |
| Only one location fails | Regional incident details and the network path. |
Name the exact product in your incident note. “Cloudflare issue” is too broad to tell a teammate whether they should inspect DNS, application logs or a management API request.
Does a 5xx error prove the network is down?
No. Cloudflare's 5xx troubleshooting documentation distinguishes failures involving the origin from other causes. For example, origin connection and timeout errors need investigation of the origin path, not an automatic conclusion that all Cloudflare traffic is broken.
Save the exact code, requested URL, timestamp and Ray ID if the response includes one. Look for a matching request in the origin logs. Avoid treating every 5xx response as the same event: a server rejecting a connection and an application returning an error give you different evidence.
If you are not the site operator, provide those details to support. Repeatedly clearing your browser data cannot repair someone else's overloaded application server.
How do I distinguish DNS problems?
First determine whether the hostname resolves at all. Compare the expected record with the result from your normal resolver and an authorized independent check. Note recent DNS changes and the time they were made.
Do not change nameservers as a diagnostic experiment. That introduces a substantial configuration change and can make the original issue harder to isolate. A local resolver failure does not establish that Cloudflare's authoritative DNS service is unavailable.
If the name resolves but HTTPS fails, move to the connection and response evidence. Resolution success is one completed step, not proof that the application behind the hostname is healthy. Keep the boundary between these checks visible in your notes.
What if the dashboard fails but my site works?
Treat serving traffic and changing configuration separately. A failed dashboard login may block a deployment or rules change without interrupting the currently deployed site. Test an actual customer journey before declaring a customer-facing outage.
For a management API timeout, record the intended change and inspect the resulting configuration when access returns. Do not assume the change failed merely because the client did not receive a response. Repeating a write can obscure which configuration is active.
For Workers, inspect the affected route, logs and upstream dependencies. A recent application change deserves attention alongside provider status. An exception in one script does not prove a Workers-wide outage.
What does a partial or regional incident mean?
Read the specific locations, products and symptoms in the notice. An incident limited to one region may block your users while a teammate elsewhere sees no errors. A partial label describes scope, not the seriousness of your own interruption.
Maintenance also needs context. Do not assume every maintenance notice causes downtime for every customer. Compare the provider's description with your observed failures and the paths your traffic uses.
When the headline seems inconsistent with your experience, see why status pages say operational when things are broken. Your regional test and the provider's overall summary can describe different parts of the same situation.
Should I use Downdetector and social reports?
Use them to spot similar reports, then compare timestamps, regions and error details. Broad complaints cannot establish whether Cloudflare, an origin server or another dependency is responsible. Several unrelated websites failing may justify a wider investigation, but it is not a complete root-cause analysis.
Once you have identified the likely boundary, follow the Cloudflare outage playbook. Preserve configuration, keep changes deliberate and verify the original customer path during recovery. Do not turn a brief unknown into a DNS migration that creates a second incident.