Your WAF starts blocking legitimate checkout traffic during a sale. How do you tell an attack from a spike, live?

Short answer

If a WAF blocks checkout during a sale, inspect per-rule counters and funnel conversion before turning anything off globally. A real sale spike should preserve the funnel shape; a bad WAF rule usually creates a sudden drop at one step, so move that rule to monitor mode and keep the rest active.

The rate did not change, the denominator did

Start with arithmetic before you start with a theory. Say checkout carries 200 POSTs a minute on an ordinary day, and one rule in your rule set has a false-positive rate of four in a thousand on that endpoint. That is 0.8 blocks a minute. Nobody has ever noticed it. It has been sitting in the audit log for eighteen months.

The sale arrives and checkout traffic goes to 2,000 POSTs a minute. The same rule, unchanged, now blocks eight a minute. Over a four-hour sale that is 1,920 customers who reached the payment step and were refused. Nothing about the WAF got worse. The rule was always wrong at this rate, and the sale merely made the absolute number large enough to reach support.

Say that out loud, because it reframes the incident. You are not hunting a new cause. You are looking for the rule that was already misfiring, and the reason it is urgent now is revenue rather than novelty.

It also tells you what to check first: is the block rate up, or only the block count? If blocks per thousand checkout requests is flat, this is a spike hitting a pre-existing false positive. If the ratio has climbed, something in the traffic genuinely changed, and now you have to work out what.

What a spike looks like that an attack does not

Real traffic arrives through a funnel and keeps the funnel's shape. Product views feed carts, carts feed checkouts, and the ratios between those steps are a property of your customers rather than of your marketing. A promotion multiplies all three. It does not usually change the ratio between them by an order of magnitude.

So the most useful live signal is a ratio, not a volume. Checkout POSTs against product-page views over the last five minutes, compared against the same ratio last Tuesday. If views went up 10x and checkouts went up 10x, you have customers. If checkouts went up 40x while views barely moved, something is arriving at one endpoint without walking there, and that is not a shopper.

Three more signals worth having on the same screen, each of which fails in a different way so you want all three:

• Session depth. How many requests does the average blocked source have in this session, and did it have a session at all before the blocked request? Attack traffic often has one request per identity.
• Source spread. Count distinct networks. A promotion spreads across the address space your customers live in; a flood is usually concentrated, and a botnet is diffuse in a way that looks unlike either. Concentration and diffuseness are both informative, but only against your own baseline.
• Downstream outcome. For the sessions that were not blocked, is the payment-authorisation success rate normal? Real customers convert. Traffic that reaches checkout and never authorises anything is not shopping.

flowchart TD
  A[Blocked rate rises] --> B{Checkout to pageview<br/>ratio preserved}
  B -->|Yes| C[Demand spike on an old<br/>false positive]
  B -->|No| D{Source spread narrow}
  D -->|Yes| E[Block by source at the edge]
  D -->|No| F[Challenge unauthenticated<br/>requests, keep WAF armed]
  C --> G[Log-only the offending rule]

The branch to watch is the left one, because it is the likely answer and the one under-investigated during an incident. Everybody wants the finding to be an attack.

You cannot tune a rule you cannot name

None of the above helps if your logs record a decision without recording why. A rule set that scores requests by accumulating an anomaly score across many rules and blocking above a threshold gives you a genuinely useful property here: a blocked request has a list of contributing rules and their scores. That list is the whole diagnosis. Which rule, which request field, which pattern.

If the log line says only blocked, then during the sale you have no live path to the answer, and your options collapse to blunt ones. Treat that as the finding of the incident. The per-rule attribution has to be in the audit log before you need it, because the traffic that reveals the problem only exists during the event you cannot afford to experiment on.

Once you can name the rule, the remedy is narrow. Set that one rule to log rather than block, on that one endpoint, and leave everything else in place. A house with a tripping circuit is fixed by finding the circuit, not by pulling the main breaker - and the analogy has a definite limit worth stating, because a WAF's main breaker is being watched by someone who will notice it open. A sale is when your traffic is worth the most to you and your checkout flow is worth the most to a card tester. Standing the WAF down for four hours because one rule is noisy trades a known revenue loss for an unknown one, and only one of those appears in a post-incident review.

Neither answer is "raise the threshold"

The temptation, under pressure, is to move the global anomaly threshold up a notch. It resolves the symptom in one change and it is the wrong change, because you have altered the sensitivity of every rule against every endpoint to fix one pairing. You will not know what you switched off, and you will not know when to switch it back.

Scope the exception the same way you would scope any other change: to the rule, the endpoint, and where possible the request field. A rule that fires on a base64 payment token in one parameter should be excepted for that parameter, not for the request. That exception is then a written artefact with an owner, and it belongs in a review queue rather than in an engineer's shell history.

The permanent fix is upstream of all of this. New rules go into log-only mode against production traffic first, and you read the counters for a week before they block anything. That week is what tells you a rule has a four-in-a-thousand rate on checkout, at a point where the number is 0.8 a minute and costs you nothing to learn.

A false-positive rate is a property of the rule and the endpoint, so it does not change when traffic does. What changes is how many customers it reaches, which is why a rule you never noticed becomes an incident on your busiest day.

© 2026 Preptima. Originally published at preptima.com.