WAF monitor mode: see what would have been blocked

The rules run identically. The only difference is at the end.

A request arrives, is evaluated against the rule set exactly as it would be under enforcement, and a decision is reached. Under enforcement that decision is applied. In monitor mode it is recorded and then discarded, and the request continues to your origin as if nothing had been evaluated.

One consequence of that distinction is easy to miss: while you are watching, nothing is being stopped. Monitor mode is an instrument, not a posture. It tells you what enforcement would do; it does not do any of it.

There are three modes in total, and this is the middle one. Off evaluates nothing, monitor evaluates and records, block evaluates and acts. There is no fourth setting and no scale between them. Tools in this category often have one, and the reflex is to look for it. Adjustment here happens through rules and exceptions rather than through a dial, as covered under rules.

Not the total. The total tells you almost nothing on its own.

Legitimate traffic that would have been stopped. This is the entire reason the mode exists. Somewhere in the record are requests from real users, your own integrations, or a partner's system, that a rule considers hostile. Each one is an outage you have not had yet, and finding them before enforcement is the difference between a controlled change and an incident.

Patterns rather than counts. A hundred matches from one source in one minute is one story; a hundred matches spread across a hundred sources over a day is a different one. The same number means opposite things, and only the shape distinguishes them.

Requests you cannot explain. The useful discipline is to treat every unexplained match as a question rather than as noise. Some will turn out to be genuine attacks, which is reassuring. Some will turn out to be a client of yours doing something unusual, which is the finding that saves you.

Your own machinery. Health checks, deployment hooks, monitoring agents, and internal scripts all make requests that look automated because they are. They are the most commonly surprised category, and they are also the easiest to fix once seen.

Long enough to see your traffic, which is a question about coverage rather than about days.

A period that contains no deployment, no marketing activity, and no monthly job has not shown you your site. The useful question is whether the window included the things that make your traffic unusual: a release, a campaign, a billing run, whatever your equivalent of a busy Friday is. Enforcement turned on after a quiet week discovers the busy week by breaking it.

The other half of the answer is qualitative. You are ready when the record contains nothing you cannot account for, which is a stronger condition than it sounds and a more useful one than any fixed duration. A site with two unexplained matches is not ready; a site with several thousand explained ones may well be.

The log holds requests the rules flagged, and knowing its boundaries keeps you from asking it the wrong questions.

It records flagged requests in near real time, batched, with sub-second latency, so what you are reading is current rather than a report from yesterday. Each entry tells you which request matched and what would have happened to it.

What it is not is a volumetric traffic dashboard. It does not tell you how much traffic your site received, nor summarise attack volume, because it only ever contains requests a rule flagged. Asking it how big an event was is asking a question it was not built to answer, and its own page in this section sets out exactly what it holds and what it does not.

The transition is a decision, and it does not have to be all at once.

Enforcement can begin on part of the site, on one path, or for one class of rule, so the first real block happens in a place you are watching closely rather than everywhere simultaneously. How to choose that first slice is set out under staged rollout, and it matters because the first enforcement is the one most likely to surprise you.

What monitor mode has bought you by that point is the list of exceptions you need before enforcement rather than after it. Writing those exceptions while nothing is broken is a calm task. Writing them during an outage, with somebody asking why checkout is failing, is the same task done badly.