How do I stop WAF logs of Health Check or probe traffic (WAF Log Suppression Condition)?

Short answer

A Conditions condition that recognizes the monitoring or probe traffic (e.g. Source IP for the IP address of the monitoring server) is added to the WAF Log Suppression Condition field of the Log Settings card in WAF Management, and Edit is clicked. The records of the requests that match the condition are not shown in the Event Logs list and in filtered reports; WAF continues to inspect these requests and, if necessary, to block them. Since the records continue to be written to disk, disk usage does not decrease, and the unfiltered WAF report counts these records. Only HTTP conditions that run on the request side can be selected in the field; if there is no condition object, it is first created on the Load Balancer → Conditions screen. If the traffic is not to enter WAF inspection at all, Whitelist Condition is used instead of suppression; in this case, the request is not inspected.

Problem: Monitoring Traffic Fills Up Event Logs

An external monitoring or scanning tool, a load test or probe requests can trigger WAF signatures. These records crowd the Event Logs list and make it harder to examine real attacks. The requests are meant to continue to be inspected and only not to appear in the list.

Solution: Two Methods

Your situation	Suitable method
Defining the condition from the interface	Method 1: Log Settings card
Defining it from the command line	Method 2: WEB-CLI

Method 1: Log Settings Card Recommended

• How it works The Event Logs record of the requests that match the WAF Log Suppression Condition is marked as suppressed: the record is written to disk and is skipped in the Event Logs and Global WAF Event Log lists and in filtered reports. The inspection, the blocking, the Dashboard counters and the lines sent to the SIEM do not change. Suppressed records do not count as AI Learning and Teacher evidence. Suppression is applied when the record is written and is not retroactive: records written before the condition is saved stay in the list.
• Where it is opened On the vService screen, WAF Management → Learning & Reporting → Log Settings card → pencil icon
• Requirement Modify permission in the WAF area; an HTTP condition that runs on the request side (modify permission in the Load Balancer area to create the condition on the Load Balancer → Conditions screen)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the condition form

On the Load Balancer → Conditions screen, Add is clicked (how to add). If a suitable condition already exists, steps 1–3 are skipped.

2

Adım 2 Define the monitoring traffic

Condition Name is entered (e.g. izleme-sunucusu). For the address of the monitoring server, Criteria = Source IP and Source IP Type = Manual are selected and the address is written in the Source IP field (e.g. 198.51.100.20). If the probe calls a specific path, a condition with the path or User-Agent header criterion can also be set up (Conditions).

3

Adım 3 Save the condition

Add in the form is clicked.

4

Adım 4 Open the WAF Management tab

The Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab is opened.

5

Adım 5 Open the Log Settings window

The pencil icon at the top right of the Log Settings card in the Learning & Reporting row is clicked; the Log Settings window opens (Log Settings Edit screen).

6

Adım 6 Select the condition

In the WAF Log Suppression Condition field, the condition from step 3 is selected. Multiple conditions are combined with and / or; the list contains only HTTP conditions that run on the request side.

7

Adım 7 Save

Edit is clicked; there is no separate deployment step. In a cluster setup, the setting is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification

1CardTR7 side

The line on the Log Settings card is examined.

ExpectedWAF logging is suppressed for requests matching: line and the izleme-sunucusu condition below it

2Event LogsTR7 side

After a request that triggers a signature is sent from the monitoring server, Event Logs is fetched again with Refresh and the Client IP tab of the filter strip is examined.

ExpectedNo new record appears for 198.51.100.20

Method 2: WEB-CLI

• How it works The --wafLogSuppressionCondition field of the waf options update command takes a condition expression; the expression consists of condition IDs and is combined with and / or (WAF scope).
• Where it is opened WEB-CLI → lb condition list · waf options update
• Requirement WEB-CLI access and modify permission in the WAF area; view permission in the Load Balancer area to read the condition object and its ID with lb condition list
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Get the condition ID

The field expects the ID of the condition, not its name. The ID is read from the id column of the list (it starts with lbConditions-):

lb condition list

2

Adım 2 Write the suppression condition

In place of <condition-id>, the ID from step 1 is written:

waf options update poolId <vService> --wafLogSuppressionCondition '<condition-id>'

Multiple conditions are written in the form '<id-1> or <id-2>'. The field replaces the existing suppression condition.

Verification

1RecordTR7 side

The setting is displayed again.

Command: waf options show poolId <vService>

ExpectedThe condition ID in the wafLogSuppressionCondition line

Common Mistakes

• Thinking that suppression will reduce disk usage. The records continue to be written to disk; the retention period depends on the Disk Management rules.
• Thinking that suppression is an exemption from inspection. A suppressed request is inspected and blocked if it exceeds the threshold; to remove the inspection entirely, Whitelist Condition is used (Is the traffic I whitelist logged at all; where does it appear on the dashboard?).
• Comparing the unfiltered report total with Event Logs. The unfiltered WAF report counts the suppressed records, Event Logs does not show them; the two totals can differ.
• Deleting the condition object. If the condition is deleted while it is used in the suppression field, the suppression changes silently: if a single condition is deleted, the suppression stops; if one is deleted in a multi-condition group, the remaining ones can suppress more broadly (Log Settings · Edit).
• Confusing it with the health check silencing in the log profile. The health check lines in the access logs of the vService are silenced with a separate setting: How do I reduce log volume (silencing health check and static file logs)?
• Writing the condition name in WEB-CLI. The field expects the condition ID; the ID is obtained with lb condition list.

How it is done in the documentation

• Log Settings · WAF Log Suppression Condition
• Log Settings · Edit
• Source IP · Manual
• WEB-CLI · waf options · The WAF Scope

Related questions

• Is the traffic I whitelist logged at all; where does it appear on the dashboard?
• How do I reduce log volume (silencing health check and static file logs)?
• What are Event Logs; which requests are logged?