Request logs #

This page is for system administrators and support staff of a host. It answers: where a request for a missing page and a request that looks like an attack are logged, what a line tells you, how personal data is kept out of the files, how much disk they take, and how to use them when a customer asks "why are visitors getting errors?".

Every format and setting below is from Request logs: 404.log and security.log, which also covers the developer interfaces. The security side has its own page: Security log.

Contents #

1. Three logs instead of one
2. Reading a 404.log line
3. Privacy by default
4. Settings
5. Disk use and rotation
6. Using the logs in support
7. Checklist

Three logs instead of one #

Exponential writes a not-found answer and a suspicious request to logs of their own, so error.log keeps only the real faults:

Each request is written to one of them, never to two: a probe that ends in a 404 is in security.log only. Nothing is blocked; the classifier only classifies (Request logs, in short).

Reading a 404.log line #

[ Oct 17 2026 09:00:04 ] [2001:db8:x:x] 404 GET /content/view/full/9999 siteaccess=site reason=node:9999 node=9999 referrer=https://example.org/news ua=5d41402a "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5)"

The reason= field is what makes the log useful to support: node:9999 is a link to content that was removed, module:wp-admin is a robot looking for another product, disabled:... is a view the siteaccess switches off.

Privacy by default #

• Addresses are masked ([RequestLogSettings] MaskIP=enabled): 203.0.x.x, 2001:db8:x:x. "The raw address is never written to a file." disabled writes it in full; the feature page says to do that "only for a site that has a reason and a legal basis for it".
• Query values are *** in 404.log; secrets and e-mail addresses in the path are masked.
• The user agent is a short hash plus its first 60 characters: "enough to tell one tool from another, not a fingerprint".
• The log viewer masks what it shows again, and the error digest is always masked.

Settings #

site.ini [RequestLogSettings] (override in settings/override/site.ini.append.php):

The log directory is var/log, or the site's own log directory with [FileSettings] UseGlobalLogDir=disabled (Storage layout). The classifier is configured in settings/requestclassifier.ini; see Security log.

Disk use and rotation #

Both logs are kernel logs of the log viewer, with rotation settings of their own in settings/logviewer.ini [RotationSettings]: 5 archives each, compressed, a size limit of 10 MB for the cronjob part logs, and a prune that removes archives of 404.log after 30 days and of security.log after 90 days. While a line is written, the writer also rotates the file at site.ini [FileSettings] LogFileMaxSize like every other log (Log rotation).

# settings/override/logviewer.ini.append.php: keep security.log longer
[RotationSettings]
Keep[security]=10
MaxAgeDays[security]=365

The prune runs when the cronjob part logs runs (it is in no default part) or when ./console exp:logs --apply --prune is called; see Log viewer and rotation.

Using the logs in support #

From a shell, the same files can be searched with the log viewer's command:

./console exp:logs --search='reason=node' --file=var/log/404.log --rotations

Checklist #

• To do: NotFoundLog=enabled and MaskIP=enabled (the shipped values) unless the customer decided otherwise in writing.
• To do: The cronjob part logs or a scheduled exp:logs --prune keeps archives within their age limits.
• To do: Support staff know the error digest and its grouping by reason=.
• To do: Retention of request logs is part of the customer's data protection documentation.

Related pages #

• Security log
• Log viewer and rotation
• Monitoring overview
• Request shield and request rules
• Request logs: 404.log and security.log (feature reference)
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.