Run monitor mode for a week before you block anything

You just installed a checkout limit and you want it to start blocking right away. If an attack is running right now, that instinct is fine. If nothing is running, you have a better option. Let the rule watch for a week and write down what it would have done.

This is monitor mode, sometimes called log-only, dry run, or shadow mode. The rule evaluates every request the same way it would in blocking mode, logs the result, and then lets the request through.

Why a new rule needs a baseline

Every checkout limit is a guess about what normal traffic looks like. Five orders an hour from one IP sounds like a lot until you remember the school office that orders supplies for every classroom from one connection. A reCAPTCHA score of 0.5 sounds like a safe cutoff until you see how many real mobile shoppers on a privacy browser score lower.

You cannot answer those questions from a settings screen. You can only answer them from your own traffic, and monitor mode collects that traffic for you without costing a single sale.

What a week shows you that a day does not

Store traffic has a weekly shape. Weekend shoppers browse differently from weekday office buyers. An email campaign on Tuesday can bring a burst of orders that looks a lot like a bot run if you only count orders per minute.

A full seven days usually covers at least one quiet stretch, one busy stretch, and one odd event. If you have a sale or a newsletter planned, try to include it in the window. That is exactly the traffic a strict rule is most likely to break.

What to record

For each rule you run in monitor mode, the log should let you answer these questions:

• How many requests would this rule have blocked?
• Which of those became paid orders, and which ended as failed or never reached the gateway?
• Did the would-be blocks cluster in time, or spread across the day?
• Which checkout route did they use (classic checkout, Checkout block, pay-for-order, add payment method)?
• Which payment method did they pick?

The second question is the one that matters most. A would-be block that later became a paid, shipped, unrefunded order is a real customer you would have turned away.

Reading the results

No would-be blocks at all

Either your traffic is clean or your threshold is too loose to catch anything. Look at the highest values the rule saw. If the busiest IP placed two orders in an hour and your limit is twenty, you have room to tighten it.

Would-be blocks that are all junk

This is the result you want. Every flagged request looks like card testing: small totals, failed payments, filler names, tight timing. Switch to blocking with some confidence.

Would-be blocks that include real buyers

Find what those buyers have in common. They might share a corporate network, a mobile carrier that routes many users through few addresses, or a payment method that retries on its own. Loosen the threshold, narrow the rule to the gateway that attackers target, or add a staff or customer exception. Then run monitor mode again.

When to skip the week

Monitor mode is for prevention, not for an attack already in progress. If failed orders are piling up as you read this, turn blocking on now. A few false positives cost less than another night of declines landing on your gateway account.

Even then, keep logging. Blocking mode logs tell you whether the rule is catching the attack, and whether real buyers are getting stuck while it does.

The steps

1. Install the rule with monitor mode on and blocking off.
2. Note the date and any planned campaigns in the coming week.
3. Let it run for seven days. Do not adjust thresholds partway, or you will be reading two different rules.
4. Export the log and match flagged entries against orders by time and email.
5. Mark each flagged entry as real buyer, junk, or unclear.
6. Adjust the threshold until real buyers fall below it.
7. Switch to blocking, and keep checking the log for a few days after.

Monitor mode is not a one-time step

Traffic changes. You add a payment method, start selling wholesale, or launch in a new country. Each of those can shift what normal looks like. When you change something big about how people buy, put the related rule back in monitor mode for a few days and check that the old numbers still fit.

The same goes for new rules. Run each one in monitor mode on its own, so you know which rule caught which request.

What this looks like in Checkout Bouncer

Checkout Bouncer has a monitor mode for its order-rate throttle. With it on, the plugin counts orders and logs the ones that would have tripped the limit, without stopping the order. The events log shows those entries with seven-day stats, and you can export them as CSV to compare against your order list.