Cloudflare Under Attack mode: when to turn it on, and what it breaks

The site is slow, the origin is at 100% CPU, and someone in the incident channel says "turn on Under Attack mode". It is one switch in the Cloudflare dashboard, and it often does stop the flood. It also stops your mobile app, your payment provider's callbacks and your uptime monitoring, and nobody notices until the next morning.

This post covers what Under Attack mode actually does, when it is the right call, how to limit the damage, and how to stop a DDoS attack with more targeted tools.

What Under Attack mode does

I'm Under Attack mode adds extra checks to help mitigate layer 7 (HTTP) DDoS attacks¹. With it on, visitors see an interstitial challenge page before your site loads. Today that page is a Cloudflare Managed Challenge, and the browser needs JavaScript to pass it.

A visitor who passes gets a cf_clearance cookie and is not challenged again until it expires. The default lifetime is 30 minutes, set under challenge passage in the security settings².

What it does not do:

• It does not touch network-layer attacks. Cloudflare mitigates layer 3 and 4 DDoS attacks automatically on every plan³. If your problem is a volumetric flood against an IP address, this switch is irrelevant.
• It does not protect an exposed origin. If attackers already know your origin's IP address, they can bypass Cloudflare entirely.
• It is not selective. Every request from every visitor on the affected hostnames is challenged, including your best customers.

The scale of both kinds of attack is large. In the first half of 2026 alone, Cloudflare reported mitigating⁴:

Cloudflare's own documentation describes it as one of the last resorts when a zone is under attack, and warns that it pauses access to your site, affects analytics and may affect API traffic¹⁵.

What it breaks

Anything that is not a person in a browser cannot solve a challenge. Before you turn it on, list what talks to the zone:

The mode also changes what your analytics see, so traffic charts from the incident window are not comparable with normal days.

When to turn it on

Under Attack mode is the right call when all of these are true:

• The attack is HTTP traffic hitting your site through Cloudflare, not traffic to your origin's IP address.
• The origin is failing or close to it, so you need relief in minutes.
• You can't yet see a pattern (a path, country, ASN or user agent) to write a targeted rule against.
• The site is mainly used in browsers, or you can exempt the API and integration paths.

If you can already see the pattern, a targeted rule is better. If the site is mostly an API, Under Attack mode will hurt you more than the attacker.

How to turn it on, and how to scope it

For the whole zone

In the Cloudflare dashboard, open the zone overview and use the Under Attack mode toggle in Quick Actions¹. It takes effect within seconds.

Through the API, Under Attack mode is the under_attack value of the zone's security_level setting:

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/security_level" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"under_attack"}'

Keep the command, and the one that sets it back, in your incident runbook, so turning it off is as easy as turning it on.

For one path, or with exceptions

You don't have to challenge the whole site. A configuration rule can turn Under Attack mode on for matching requests only, such as /login or /search, where the flood is landing¹. The same kind of rule can turn it off for paths that must keep working, such as /api/ or your payment callback route.

Scoping to the attacked path is usually the best compromise. Customers browsing the rest of the site see nothing, and the attacker's traffic to the expensive endpoint gets challenged.

How to stop a DDoS attack on Cloudflare, in order

Under Attack mode is one step in a sequence. When an HTTP flood starts, work through this list:

1. 1

   Confirm the traffic comes through Cloudflare. If the origin's IP address is exposed, attackers can bypass the edge. Allow only Cloudflare's IP ranges at the origin firewall, and move the origin if its address is widely known.

2. 2

   Look at Security Events and analytics. Find what the attack has in common: path, method, country, ASN, user agent, query string. Even a rough pattern is enough for a first rule.

3. 3

   Write a targeted rule. A WAF custom rule with a managed challenge or block on that pattern, or a rate limiting rule on the attacked path. Our post on Cloudflare rate limiting rules covers thresholds.

4. 4

   Check the HTTP DDoS managed ruleset. It is always on. You can change its sensitivity and action with an override, and Cloudflare recommends keeping the default high sensitivity⁶.

5. 5

   Cache what you can. Requests served from cache never reach the origin. A flood against a cacheable page often ends with one cache rule.

6. 6

   Use Under Attack mode if the origin is still failing, scoped as tightly as you can, while you keep looking for the pattern.

7. 7

   Plan the exit. Once a targeted rule holds, turn Under Attack mode off, watch for ten minutes, and record what you changed and why.

Our Learn article on how to stop a DDoS attack covers the wider picture, including attacks that aren't on Cloudflare yet. For what Cloudflare's latest attack data means for your configuration, see what Cloudflare's H1 2026 DDoS report means for your edge.

After the incident

Under Attack mode left on is a common finding weeks after an incident. Close the loop:

• Turn it off and confirm the security level is back to its usual value.
• Check the integrations in the table above. Look for orders stuck in "pending", failed partner calls and app error reports during the incident window.
• Keep the targeted rules that worked, with a review date, and remove the ones that didn't.
• Write down the pattern and the rule that stopped it, so the next on-call engineer starts at step 3, not step 1.

Under attack and not on Cloudflare yet

If the site is not behind Cloudflare, none of the above applies until it is. Vigilbase runs emergency Cloudflare onboarding to move exposed web traffic onto Cloudflare and stabilise it. For a single domain that should have been protected before the attack, Vigilbase Shield puts it behind Cloudflare with managed WAF rules and DDoS protection on a monthly plan. How we operate Cloudflare DDoS protection day to day, including who leads an incident, is set by the Managed Cloudflare package and the SLA.