What to Do When Cloudflare Is Down

When a site behind Cloudflare fails, preserve the current configuration and work out which layer is broken. Switching DNS or bypassing the proxy immediately can create new problems before you have established what failed in the first place.

Check the official Cloudflare System Status page for the affected product and region. If the symptoms are still ambiguous, use Is Cloudflare down?. A Cloudflare error page alone is not confirmation of a provider-wide outage.

Stop changes that make the incident harder to read

Pause unrelated deployments and configuration edits on the affected service. Record recent changes, the failed URL, time, error code and Ray ID if available. Keep a note of any management API request whose result is unknown.

Do not toggle proxy settings repeatedly, move nameservers or disable security rules to see whether something changes. Each action alters the request path. You need a reason for the change, a way to judge its result and a way to restore the prior state.

If a tested incident procedure already exists, follow it with a named owner. Keep its scope tied to the observed problem. A DNS issue, a Worker exception and a dashboard outage do not automatically benefit from the same fallback.

Confirm customer impact and tell the team

Test a representative customer action from the affected location if possible. Compare another region or network, and separate a failed management interface from failed public traffic. Record successful paths as well as failures.

Use a message like this:

We are seeing [symptom] on [hostname/service] from [location] since [time and timezone]. Cloudflare has [confirmed a matching incident / not confirmed the cause]. [Customer action] is affected; [other action] still works. Hold [specific changes]. [Owner] will update at [time].

Give customer support the same verified boundary in simpler language. Downdetector and social reports may support the investigation, but avoid assigning cause from report volume. If the service itself is unavailable, use a communication channel that does not depend on it.

Check the origin before bypassing anything

For proxied traffic, inspect origin health and logs. Cloudflare's 5xx error guidance is the reference for interpreting the specific error. Collect evidence rather than assuming every response with Cloudflare branding was caused inside Cloudflare.

An authorized origin check can help distinguish application failure from the path through the proxy. Keep the hostname and TLS requirements in mind, and use your team's existing diagnostic procedure. Do not expose a private origin or publish its address as a workaround.

Only use a bypass if it is already tested and suitable for the affected service. Confirm certificate coverage, origin capacity, access controls and which protections the normal path provides. If those conditions are unknown, a rushed bypass is not a reliable recovery plan.

Respond according to the affected component

For DNS, compare records and resolver behavior before editing. Changing an authoritative record does not fix a recursive resolver problem. Keep a record of intended values and avoid treating delayed observations after a change as proof that the new value is wrong.

For Workers, preserve logs and identify whether the failure began with a deployment. Use an established rollback when evidence points to your change and the deployment controls are available. If an upstream API fails, handle that dependency rather than rewriting a healthy Worker during the incident.

For dashboard or management API failures, leave serving traffic alone if it is healthy. Queue nonessential configuration work in a note. Before retrying any interrupted change, inspect the actual configuration to determine whether the earlier request took effect.

For regional network problems, test from representative locations and follow the incident's scope. A successful request from your laptop may not represent the users who are still affected. Avoid declaring recovery from one convenient vantage point.

Keep useful work moving

Have one responder follow service updates while others prepare support replies, review recent changes or work on unrelated local development. If public traffic is healthy and only management is affected, defer nonessential deploys instead of treating the entire business as stopped.

Document blocked actions precisely. “Cannot update this rule” and “customers cannot sign in” imply different priorities. Keep a short queue of deferred changes with owners so they do not all run simultaneously when access returns.

Avoid speculative architectural changes during the wait. Capture any resilience improvement as a follow-up with an example of the actual failure it would address. That gives the later design discussion evidence rather than panic.

Verify recovery through the full request path

The shared status-page guide explains why an overall status update may not settle every regional or application issue. Use it as context, then test your service.

1. Confirm DNS resolves as expected from relevant locations.
2. Test a representative HTTPS request and customer journey.
3. Check origin and Worker errors alongside response results.
4. Inspect any configuration changes with uncertain outcomes.
5. Restore temporary measures through their recorded rollback steps.
6. Resume queued deployments and management changes deliberately.
7. Tell the team which regions and workflows you verified.

Keep monitoring the specific symptom that started the incident. A dashboard loading successfully is not a substitute for testing checkout, login or the API endpoint your users need.

An optional break once coverage is arranged

If the response is covered, join the Nines ping list for a tiny browser arcade that opens during qualifying official developer-tool outages. Yellow or degraded banners alone do not unlock it. Customer recovery still needs an owner while everyone else waits.