You turn on a browser challenge for all traffic at the front door during a flood — who breaks, and how should you have sequenced it?

## The shape of enforcement day The flood is live, the challenge is written and tested, and somebody flips it on for all traffic at once. Within minutes two things happen. The flood keeps arriving, because the part of it made of real hosts pays the toll. And a support queue starts filling with people and machines the challenge locked out — which is the part nobody rehearsed. The person who flipped the switch owns both. ## Who breaks, in the order they call **Machine clients that never had a browser.** A partner's server-to-server integration issues an HTTP request, reads the response, and stops. It does not follow a redirect chain, does not persist a token, and certainly does not execute a challenge. It gets the interstitial back as a body, fails to parse it, and either errors loudly or — worse — retries in a loop, adding load to the thing you are defending. **Inbound callbacks.** A payments provider posting a result to a fixed path is a machine you cannot instrument and cannot ask to change. Challenging it does not degrade a user experience; it drops financial state on the floor, and the failure surfaces later as reconciliation work. **Frozen clients.** An old mobile build with an embedded view, shipped years ago and still in use, cannot be fixed by anything you deploy today. Whatever it does when challenged is what it will keep doing. **Clients that cannot complete an interstitial.** No-JavaScript browsers, text-mode clients, and assistive setups where a redirecting, self-refreshing interstitial breaks the flow. These users rarely file tickets; they simply leave, which is why they do not appear in the incident channel and do appear in the conversion numbers. ## The sequence that would have avoided most of it 1. **Observe-only first.** Run the challenge logic and record the verdict without acting on it. What you want out of this is a breakdown of what *would* have been challenged, by path and by client shape — and specifically a list of paths where the traffic is entirely non-browser. That list is your exemption list, discovered rather than remembered. 2. **Exempt the machine paths before enforcing, and scope them tightly.** Exempt the specific callback path and method, not the whole front door; require that path to carry its own credential, so the exemption is not simply an open door. An exemption expressed as a source-address allowlist across everything is the widest possible hole, and it is exactly the hole an attacker looks for once the challenge is public. 3. **Enforce narrowly.** On the paths actually under pressure, or only above a traffic threshold, so normal days look normal and the blast radius on enforcement day is bounded. 4. **Keep the way back.** One switch, known to the on-call, that returns the front door to its previous behaviour without a deploy. ## What the list becomes The exemption list is the durable cost of this control, not the CPU. Entries get added under outage pressure, by whoever had access, with no note about why. Six months later there are dozens, nobody can name what each protects, and removing one risks breaking something invisible — so nobody does. The only cheap moment to prevent that is the moment of adding: every entry gets a named owner and an expiry date at creation, and periodically the whole set is re-run in observe-only mode to see which entries would still fail today. Entries that would pass are deleted. ## Measuring whether it worked Watch three things, and be careful about the direction of each claim. The rate at which challenges are issued tells you how much traffic is unproven, not how much is hostile. The solve rate tells you the population can pass, not that it is friendly. The one that matters is completion of real user journeys — sign-up, checkout — because that is the only number that reflects the people the control locked out. A high solve rate with unchanged upstream volume is the signature outcome: the challenge is working exactly as designed, the flood is paying the toll, and the problem has become a capacity problem.