I see rule 369999 in Debug Mode Logs or SIEM records; what is it?

Short answer

369999 is not an attack signature but a marker that shows the request was blocked in Blocking Mode because its WAF scan could not be completed within the 2-second time limit; since it is not in the signature library, it cannot be searched for in Signature & Rule Library. The uninspected request is blocked so that it does not reach the Backend Service, and the client receives the same response as with an ordinary WAF block (Blocking Status Code, default 418). This record is formed only in a host group in Blocking mode and while Fail-open in the Request Body Limits window is off (default); in Learning and Monitor modes, in requests that come with the Teacher and Conditional Learning identities, and while Fail-open is on, the request is passed and no record is formed. The blocked request does not appear in Event Logs, in Global WAF Event Log, in the WAF panels of the Dashboard or in WAF Report; it is found only in the WAF box of the Debug Mode Logs record (Verdict Attack blocked — scan timed out, Triggered rules 369999) and in the WAF information sent to the log server (wafInfo). The 100 points and the 2000 ms WAF time in wafInfo are not measurements but fixed values. The time limit is not a setting; if the record is seen often, the requests whose scan takes long are found and the scanned body is reduced (Max. Body Size to Process(kB)), and if needed, Fail-open is turned on: Why does a request that received 418 not appear in Event Logs?

How Does It Occur?

1. The request enters the WAF inspection. The requests that match the Whitelist Condition and the requests counted as static content do not enter the inspection, so they never produce this record.
2. If the scan does not conclude within 2 seconds, it is cut off. Usual scans take milliseconds; exceeding the time usually points to a request whose scan takes unusually long (a very large or deep body, a large number of parameters). Waiting for the body to arrive from the network does not count toward this duration (What happens to a request if the scan exceeds a certain time (2-second scan limit)?).
3. If the request belongs to a host group in Blocking Mode and Fail-open is off, it is blocked; rule number 369999 is added to this decision. In groups in Learning Mode and Monitor Mode, in requests recognized by Teacher and requests that come with the Conditional Learning identity, and while Fail-open is on, the request is passed; no 369999 record is formed and the request leaves no WAF trace anywhere.
4. The blocking response of the vService is returned to the blocked client: the Blocking Page content and the Blocking Status Code (default 418); if there is a Conditional Blocking Pages record whose condition holds, its page and code. The response is the same as with an ordinary WAF block; the client does not see that a timeout occurred.
5. Since the scan did not reach the stage at which it writes a record, no Event Logs record is formed.

Where Does It Appear?

Surface	369999
Debug Mode Logs (if Debug mode is on at the time of the event)	Security Action = WAF · Attack blocked — scan timed out · 1 attacks; in the WAF box on the Summary tab, Verdict = Attack blocked — scan timed out, Attacks = 1, Triggered rules = 369999. Since the rule cannot be resolved to a name, only the number is written. In the Security action filter, it is selected as WAF · Timeout
Log server: CEF and TR7 JSON formats	The record below in the wafInfo field; the isWafAttack field shows the blocking
Log server: TR7 WAF Log format	The line itself is the record below
HTTP Logs	The rule does not appear; the request is recorded with the Blocking Status Code (default 418)
Event Logs · Global WAF Event Log	Does not appear
WAF Inspection Distribution · WAF Blocked Requests · WAF Report	Not counted
Signature & Rule Library · OWASP Rules	None; 369999 cannot be searched for and its status cannot be changed

Record Content

In a request blocked by a timeout, the wafInfo sent to the log server carries the same fixed values every time:

Field	Value	Meaning
totalScore	100	Fixed; it is not the real score of the request
attacks[0].id	369999	A marker that shows the scan could not be completed within the time limit
attacks[0].score	100	Fixed
attacks[0].scope	raw	Fixed
attacks[0].severity	high	Fixed
wafTime	2000	The time limit (ms); it is not the measured scan time

The request ID (uid) and decision (action) fields found in an ordinary WAF record are not included in this record. On the log server, timeouts are filtered as a separate class with the attacks[0].id = 369999 value (How do I send WAF logs to a SIEM; which formats carry attack information in a structured way (CEF, JSON)?). Passed timeouts (Learning and Monitor modes, Teacher and Conditional learning requests, Fail-open on) send no WAF information to the log server.

If the Record Is Seen Often

• In Debug Mode Logs, the Path, body size and Content-Type values of the rows with 369999 are compared; a record that repeats at the same endpoint shows that the scan of the request body at that endpoint takes long. Diagnosis steps: Why does a request that received 418 not appear in Event Logs?
• The scanned body is reduced across the vService: a body that exceeds the larger of the Max. Body Size to Process(kB) value and the Buffer Size(kB) value in the vService Limits profile is not parsed and not scanned; what happens to it is determined by the Block Unparsed Contents setting on the Raw tab of the page type (Why does a request that received 418 not appear in Event Logs?).
• For requests with large bodies: Large POST requests are blocked or cut off; why? · For file uploads: File uploads are being blocked by the WAF; how do I fix it?
• If a specific endpoint that receives requests from a trusted source is to be excluded from the inspection: Can I exempt certain IPs or requests from WAF inspection entirely (Whitelist Condition)?
• If the blocks affect the service and the request cannot be reduced, Fail-open in the Request Body Limits window is turned on (off by default; in WEB-CLI, waf options update poolId <vService> --failOpen true). While it is on, these requests pass without being scanned and no 369999 record is formed; since a request that deliberately prolongs the scan can bypass the WAF, the option is turned on only if these blocks affect the service (Why does a request that received 418 not appear in Event Logs?).
• The 2-second time limit cannot be changed from the interface or from WEB-CLI.

Common Misconceptions

• "369999 is an attack signature." It is a marker that shows the scan could not be completed within the time limit; it is not in Signature & Rule Library.
• "The 100 points and the 2000 ms in the record are the real values of the request." Both values are the same in every timeout record.
• "369999 is also seen in a group in Learning or Monitor mode." In these modes, a request whose scan cannot be completed is passed and no record is formed; 369999 is seen only in Blocking mode, while Fail-open is off. The only exception is the scan being cut off while the WAF rules are being loaded and before the host group is determined: if the vService has a group in Blocking mode, this request is blocked and appears with 369999 even if it comes to a group in Learning or Monitor mode (WAF Mode · Blocking Mode).
• "While Fail-open is on, the absence of a 369999 record shows that there is no timeout." While Fail-open is on, the requests whose scan cannot be completed pass without being scanned and leave no trace anywhere.

How it is done in the documentation

• WAF Mode · Blocking Mode
• Debug Logs · Summary Tab
• CEF Format (HTTP) · WAF Information
• TR7 WAF Log Format (HTTP)
• Request Body Limits · The Request Body Limits Edit Screen

Related questions

• Why does a request that received 418 not appear in Event Logs?
• What happens to a request if the scan exceeds a certain time (2-second scan limit)?
• Can a request be blocked with 418 even in Learning or Monitor mode?
• Which decisions does the WAF make for a request; what do Action in Event Logs and Verdict in Debug Mode Logs mean?