No records appear in Event Logs; why?
Short answer
Event Logs writes a record in only two cases: when the total score of the request reaches the blocking threshold, or when a signature in Monitor state is triggered. If the screen is empty, the most common reason is that the host group is in Learning Mode: when the WAF is first turned on, the host group starts in this mode and requests are written not to Event Logs but to the learning log. Requests that arrive with the Conditional Learning identity take the same path even in a group in Blocking mode. Other reasons: the traffic contains no attack that exceeds the threshold; requests that match Whitelist Condition or fall within the scope of Do not WAF static contents never enter the WAF; records that match WAF Log Suppression Condition are not shown in the list; the Date Range, Line Limit, Request Unique ID and Log Filter values on the screen or the saved filter strip selections narrow the list; requests blocked at the scan time limit do not write a record, and old records are deleted by Auto Disk Cleanup (by default, files older than 12 months, or the oldest ones when disk usage exceeds 90%). The list does not refresh on its own; new records are fetched with Refresh.
Problem: Event Logs Is Empty
There are no records at all on the Event Logs screen of the vService. It is not clear whether this is because there is no attack, because the record was never produced, or because the produced record is hidden on the screen. An empty list alone does not show that there was no attack.
Possible Causes
| Cause | How to tell it apart |
|---|---|
| The host group is in Learning Mode | On the mode card in WAF Management, "Learning mode — rules are not enforced yet"; in the WAF Inspection Distribution panel on the Dashboard, the Learning series has values |
| The requests carry the Conditional Learning identity (IP, header or cookie) | The "Conditional learning is on — the analyst is recognised by …" sentence on the Learning Methods card; the Learning series has values even though the group is in Blocking or Monitor mode |
| There is no attack that exceeds the threshold | The Blocked, Monitor and Teacher series are zero; the traffic is in the Clean series |
| The requests never enter the WAF (Whitelist Condition or static content) | The Whitelisted series has values; on the Whitelist & Blacklist card, "Requests matching this condition skips WAF inspection:" or "Static content bypasses WAF inspection" |
| The records match WAF Log Suppression Condition | The "WAF logging is suppressed for requests matching:" row on the Log Settings card; the list is empty even though the Blocked or Monitor series has values |
| The screen scope narrows the list | Active filter labels under the filter strip (e.g. "Request Unique ID: …", "1 advanced filter(s)"); a time range in the title of the server filter tab that does not cover the event |
| The requests were blocked at the scan time limit in Blocking mode | The user receives 418, but it does not appear in any series; in Debug Mode Logs, Security action is WAF · Attack blocked — scan timed out (Why does a request that received 418 not appear in Event Logs?) |
| Old records were deleted | The searched date is older than the Auto Disk Cleanup limit; in the File Management list, there is no WAF logs file for that month |
| In a cluster, the peer device cannot be reached | The list contains the records of only one device; a single device name in the Source column |
Definitive rules:
- An Event Logs record is written at the end of the scan and is created in only two cases: when the total score of the request reaches the blocking threshold, or when a signature in Monitor state is triggered (In which mode is an Event Logs record created and in which is it not; are attacks below the threshold also logged?). Ordinary signature matches that stay below the threshold are not recorded.
- In a group in Monitor Mode, a request that exceeds the threshold is not blocked but is recorded ("Not blocked — Monitor mode"). A request recognized by Teacher is not blocked either; if its score reaches the threshold, it is recorded, according to the identity that recognized it, with the "Not blocked — Teacher IP matched", "Not blocked — Teacher cookie matched" or "Not blocked — Teacher header matched" decision.
- In a group in Learning mode, signature hits are not added to the score and no blocking decision is made; in requests that arrive with the Conditional learning identity, no score is accumulated. In both cases, the record is written not to Event Logs but to the learning log. Even if the Conditional learning switch is turned off, matching continues as long as the identity fields are filled; the identity fields are cleared while the switch is on, and the change is saved.
- Do not WAF static contents is on by default: GET requests that have a common static file extension and carry no query and no body do not enter the WAF and are counted in the Whitelisted series (Which requests are treated as "static content" and excluded from WAF inspection (extension, method, query and body conditions); is this safe?).
- Suppressed records continue to be written to the file; they are not shown in the Event Logs and Global WAF Event Log lists. When the condition is narrowed, only the records written from then on appear in the list.
- Request Unique ID, Date Range, Line Limit, Log filter and the selections in the filter strip are stored per user and are common to the Event Logs screens of all vServices: the screen also comes with the same scope the next time it is opened, and a Request Unique ID entered on one vService also narrows the list on the screen of another vService. Global WAF Event Log stores its own scope separately.
- In a cluster, each device keeps its own records; the screen combines the records of the two devices in a single list and shows the device that the record came from in the Source column. When a device cannot be reached, only the records of the other one are listed (scope and limits).
How to Diagnose?
- Left Monitor Panel → WAF-Protected vServices → vService → WAF Management is opened. The mode of the group is read on the mode card at the top: "Learning mode — rules are not enforced yet", "Attacks are only monitored, not blocked" or "Attacks are blocked" (mode strip). If there are multiple host groups, the card of each group is read separately.
- On the same screen, the Conditional learning sentence on the Learning Methods card and the "WAF logging is suppressed for requests matching:" row on the Log Settings card in the Learning & Reporting section, and the condition sentence on the Whitelist & Blacklist card in the Inspection & Blocking section are examined.
- On the Dashboard tab of the vService, the series in the WAF Inspection Distribution panel are examined (What do the Whitelisted, Clean, Blocked, Monitor, Teacher and Learning categories in WAF Inspection Distribution mean?): if Learning has values, the cause is the one in step 1 or 2; if Whitelisted has values, it is an exemption; if only Clean has values, there is no attack that exceeds the threshold. If the list is empty even though Blocked or Monitor has values, the cause is the suppression condition or the screen scope.
- On the Event Logs tab, the active filter labels under the filter strip are examined; if there is a saved Request Unique ID, advanced filter or tab selection, the label is removed with its close mark.
- On the server filter tab, Date Range is set so that it covers the time when the event occurred, and Save & Get Logs is clicked (Save & Get Logs). If the vService is not known, the same search is done on the Configuration Menu → WAF → Global WAF Event Log screen (Can I see the WAF logs of all vServices on one screen (Global WAF Event Log)?).
- If there is no record anywhere even though the user received 418, the scan time limit is examined with Debug Mode Logs: Why does a request that received 418 not appear in Event Logs?
- If the searched date is old, it is examined on the File Management tab of the Configuration Menu → Settings → Device Management → Disk Management screen whether the WAF Logs files for that month are still there; the limits of the automatic cleanup are in the Auto Disk Cleanup setting on the same screen.
Solution
The solution depends on the cause; the case caused by the screen scope is described step by step on this page, and the others on the related pages.
| Your situation | Suitable path |
|---|---|
| A filter, the date range or a saved Request Unique ID narrows the list | Resetting the Event Logs scope |
| The host group is in Learning mode; it needs to produce records | When should I move from Learning to Monitor and from Monitor to Blocking? |
| The records are hidden because of WAF Log Suppression Condition | Why does a request that received 418 not appear in Event Logs? (narrowing WAF Log Suppression Condition) |
| The requests do not enter the WAF because of Whitelist condition or static content | Can I exempt certain IPs or requests from WAF inspection entirely (Whitelist Condition)? |
| The Conditional learning identity is broader than necessary | Can I still keep learning certain traffic while in Blocking mode (Conditional Learning)? |
Resetting the Event Logs Scope
- How it works The server filter determines which records are fetched from the server, and the filter strip determines which of the fetched records are shown. Since both are stored per user, the values left from a previous search are cleared and the records are fetched again.
- Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs → server filter tab
- Requirement WAF permission
- Scope The Event Logs view of this user on all vServices; the WAF settings and the records do not change
Step-by-Step Configuration
Left Monitor Panel → WAF-Protected vServices → vService → Event Logs is opened.
The active filter labels listed under the filter strip (e.g. a Client IP or Path selection) are removed with their close mark.
The fixed tab at the beginning of the filter strip, whose title shows the selected time range, is clicked. If the strip is closed, it is first opened with the Filter button on the toolbar.
Date Range (default Last 7 day(s)) is selected so that it covers the time when the event occurred. Line Limit (default 1,000, at most 20,000) is the maximum number of records to be fetched; when the limit is reached, the older records of the range do not enter the list.
The value in the Request Unique ID field is deleted; while the field is filled in, only that request is searched for.
If a condition is defined in the Log Filter field, Remove Filter is clicked.
Save & Get Logs is clicked; the records are fetched from the server with the new scope. The button becomes active only when a value is changed; if no value has changed, the records are fetched again with Refresh on the toolbar.
Verification
The title of the server filter tab and the Page Information row under the table are examined.
Only the time range in the title; no active filter labelCommon Mistakes
- Interpreting the empty screen as meaning that there is no attack or that there is a fault. In Learning mode and with traffic that does not exceed the threshold, an empty screen is the expected behavior.
- Forgetting the saved Request Unique ID. The value is stored per user and applies on all vServices; an ID left from a search made on another vService reduces the list to a single request.
- Thinking that the screen refreshes on its own. The list is fetched when it is opened, with Refresh and when the server filter is changed; there is no time-based refresh.
- Thinking that turning off the Conditional learning switch is enough. As long as the identity fields are filled, matching continues and these requests do not go to Event Logs; the fields are cleared while the switch is on and the change is saved, and only after that is the switch turned off.
- Expecting old records after narrowing the suppression condition. Suppression is marked while the record is written; after the condition changes, only new records appear.
- Trying to find the searched record by increasing Line Limit. If the searched record is known, narrowing with Log filter is faster; Line Limit counts the records that match the filter, and the server reads backward from the newest record until the limit is reached.
How it is done in the documentation
Related questions
- In which mode is an Event Logs record created and in which is it not; are attacks below the threshold also logged?
- What are Event Logs; which requests are logged?
- Is the traffic I whitelist logged at all; where does it appear on the dashboard?
- Why does a request that received 418 not appear in Event Logs?
