Web Server Logging & Monitoring Checklist: 5 Checks (2026)

The server went down overnight. You open the access log and it is empty: not quiet, empty. Rotation ran a fortnight ago, the new file came back with the wrong permissions, and the server has been dropping log writes ever since. This page documents the 5 checks in the CtrlOps Logging and Monitoring audit, in the order the audit runs them.

Every threshold below is transcribed from the audit script itself. Four of these checks are about whether you will have a record when you need one, and the fifth is about whether anything inspects a request before your application does.

Key takeaways

Five checks, no HIGH severity, and one of them is the only check in the category that fails for something being absent rather than wrong.

• Four are MEDIUM and one is LOW. Nothing here is HIGH, because none of it stops an attack. What it decides is whether you can reconstruct one.
• Two need root: log permissions and rotation, because both read inside /var/log/nginx, /var/log/apache2 or /var/log/httpd.
• Only access logging can fail, and only when no access log is configured anywhere. Everything else warns.
• The WAF check draws a line that matters. Fail2Ban and CrowdSec ban an IP after a request has been served. A WAF inspects the request before it is handled. The audit reports the first as a warning rather than counting it as the second.
• The whole audit takes about 12 seconds when CtrlOps runs it over your existing SSH connection, against roughly 15 minutes of grep and stat per host by hand.

Check 1: Is access logging enabled everywhere?

The access log is the only record of what was requested, by whom and when. Without it, an incident investigation starts and ends with guesswork: no source addresses, no request paths, no timeline, nothing to hand an insurer or a client.

The audit counts access_log directives in the Nginx config, separating those whose value is literally off from the rest, and counts CustomLog or TransferLog in Apache. That separation is deliberate: an earlier version matched the string off anywhere in the line and treated /var/log/nginx/offers.log as disabled logging.

How to check manually

grep -rnE '^[[:space:]]*access_log' /etc/nginx/ | grep -v '#'
grep -rnE '^[[:space:]]*access_log[[:space:]]+off[[:space:]]*;' /etc/nginx/ | grep -v '#'
grep -rniE '^[[:space:]]*(CustomLog|TransferLog)' /etc/apache2/ /etc/httpd/ 2>/dev/null | grep -v '#'

sudo tail -1 /var/log/nginx/access.log

The warning is the one worth investigating rather than dismissing. Turning off logging for an image directory is a reasonable performance decision. Turning it off for a high-traffic API endpoint to save disk is how the one route worth investigating becomes the one route with no history.

How to fix it

# Per site, so traffic can be separated without parsing one huge file
access_log /var/log/nginx/sitename-access.log combined;

CustomLog /var/log/apache2/sitename-access.log combined

Use the combined format rather than common: it adds the referer and user agent, which are what let you tell a scanner apart from a browser after the fact.

Check 2: Is error logging configured at a production level?

The error log is where the first clue lives in almost every debugging session: an upstream timeout, a permission denial, a worker crash. Set too high and those never appear. Set to debug in production, the log fills the disk and can record request bodies, which means credentials in a file that ships to wherever your logs go.

The audit reads the first error_log directive from Nginx and the first ErrorLog or LogLevel from Apache, then checks whether either names debug or trace.

How to check manually

grep -rnE '^[[:space:]]*error_log' /etc/nginx/ | grep -v '#'
grep -rniE '^[[:space:]]*(ErrorLog|LogLevel)' /etc/apache2/ /etc/httpd/ 2>/dev/null | grep -v '#'

Note that the check reads the first directive it finds rather than every one. A global warn with a debug override on one vhost can pass, so if you deliberately raised the level somewhere, that is on your list rather than the audit's.

How to fix it

error_log /var/log/nginx/error.log warn;

ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn

warn captures warnings, errors and everything more severe, which is the right production floor. Raise it to info for a specific troubleshooting session and put a reminder somewhere to lower it again.

Check 3: Are log files world-readable?

Access logs carry more than addresses. They carry every requested URL, which on a badly designed application includes session tokens, password reset links, API keys in query strings and internal paths nobody meant to publish. World-readable means every account on the host can read all of it, including whatever account your application runs as.

The audit looks in the web server log directories for files with the world-readable bit and names up to three.

How to check manually

sudo find /var/log/nginx /var/log/apache2 /var/log/httpd -maxdepth 1 -type f -perm -004 2>/dev/null

sudo ls -la /var/log/nginx/

The check reads the world-readable bit only. It does not check whether the worker user can write to the logs, which is the other permission question worth asking, so verify ownership by hand while you are there.

How to fix it

sudo chown root:adm /var/log/nginx/*.log
sudo chmod 640 /var/log/nginx/*.log

# RHEL family has no adm group by default
sudo chown root:root /var/log/httpd/*.log
sudo chmod 640 /var/log/httpd/*.log

The master process opens the log files as root and passes the descriptors to the workers, so the worker user needs no permission on them at all. Then fix the rotation config, or the next rotated file arrives with default permissions and undoes this:

create 0640 root adm

Check 4: Is log rotation keeping up?

A site producing 50 MB of logs a day fills 18 GB in a year, in one file that takes half a minute to open. On a modest VPS that is a full disk, and a full disk stops the database, the application and the web server at the same moment.

The audit checks three things in order: whether logrotate is installed at all, whether any log file is over 100 MB, and whether a logrotate config exists for the web server.

How to check manually

command -v logrotate || echo "logrotate not installed"
ls /etc/logrotate.d/nginx /etc/logrotate.d/apache2 /etc/logrotate.d/httpd 2>/dev/null

sudo find /var/log/nginx /var/log/apache2 /var/log/httpd -maxdepth 1 -type f -size +100M 2>/dev/null
cat /var/lib/logrotate/status 2>/dev/null | head

A file over 100 MB with rotation configured is the most useful of the three, because it means rotation exists and is not keeping pace: either the schedule is too slow for the traffic, or the postrotate step is failing and the server is still writing to the rotated file.

How to fix it

# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 "$(cat /var/run/nginx.pid)"
    endscript
}

Test it without rotating anything:

sudo logrotate -d /etc/logrotate.d/nginx

Check 5: Is there a WAF in front of the application?

A web application firewall inspects the request before your application handles it, and refuses the ones that match known attack shapes: injection strings, traversal sequences, the scanner payloads every public host receives continuously. It is not a substitute for input validation. It catches what the code missed, including the bug in a dependency nobody has patched yet.

The audit looks for ModSecurity in the Apache module list or in either config, for NAXSI in the Nginx config, and for a Cloudflare signature in the response headers. Separately, it detects Fail2Ban and CrowdSec, and reports them as a distinct and weaker case.

How to check manually

apache2ctl -M 2>/dev/null | grep -i security
nginx -V 2>&1 | grep -iE 'modsecurity|naxsi'
grep -rniE 'modsecurity[[:space:]]*on|SecRuleEngine[[:space:]]*On' /etc/nginx/ /etc/apache2/ /etc/httpd/ 2>/dev/null

curl -sI https://yourdomain.com | grep -iE 'cf-ray|server: cloudflare|x-sucuri'

The separation between a WAF and log-based banning is the point of this check. Fail2Ban is genuinely useful and has its own check in the VPS logging audit. It watches logs and bans repeat offenders, which stops brute force. It cannot stop the first request, which is all an SQL injection needs.

How to fix it

# ModSecurity with the OWASP Core Rule Set, Debian and Ubuntu
sudo apt install libapache2-mod-security2 modsecurity-crs
sudo a2enmod security2
sudo systemctl reload apache2

Start in detection mode and read what it would have blocked before you let it block anything:

# /etc/modsecurity/modsecurity.conf
SecRuleEngine DetectionOnly

Run that way for a full traffic cycle, tune the rules that fire on legitimate requests, then switch to SecRuleEngine On.

What this audit does not cover

This audit reads logging configuration, log file permissions, rotation state and request filtering. It does not check:

• HTTP response headers. HSTS, CSP, frame protection and cookie flags are the Security Headers audit.
• TLS and certificates. Protocol versions, ciphers and certificate expiry are the TLS Configuration audit.
• What the server exposes. Directory listing, dotfiles, backups and status endpoints are the Content Exposure audit.
• Host-level logging. Fail2Ban state, log rotation health across the system and failed SSH login volume are the VPS Logging and Monitoring audit.
• What is in the logs. The audit checks that logging works and is protected. It does not read your logs, look for attacks in them, or alert on anything.
• Log shipping and retention. Whether logs reach a central store, and how long they are kept there, is a question about the receiving end rather than about this host.

The manual audit problem at scale

Five checks by hand is fifteen to twenty minutes per server, and the part that takes the time is not the commands. It is confirming that a log which is configured is also being written to, which means checking the directive, then the file, then the timestamp, then the rotation config that will recreate it tomorrow.

Across ten servers that is most of a morning, and the failure it is designed to catch, a log that exists and is empty, is precisely the one that a config-only check reports as healthy.

How CtrlOps runs all 5 checks in one click

Instead of running these commands on every server by hand, CtrlOps runs the whole Logging and Monitoring audit over the SSH connection you already have open. Nothing is installed on the server: no agent, no daemon, no package, no new credentials. The checks are read-only POSIX shell that executes, streams its results back, and leaves nothing behind.

Watch it run

The recording below walks through the SSH and Access audit rather than this one, but the flow is identical for every audit in the catalog: pick it, watch the checks stream in, read the score, send the failures to the AI Terminal.

Step 1: Open the Audit tab

Connect to your server in CtrlOps and open the Audit tab in the left sidebar.

Step 2: Select Logging & Monitoring

Choose it from the Web Server category. All 5 checks are listed with their descriptions, severity levels and the estimated run time, about 12 seconds in total. Two of them need root, and the UI says so before you run anything.

Step 3: Run it

The audit runs over your existing SSH session. Results stream in as they complete, so you watch each check pass, warn or fail rather than waiting on a final report.

Step 4: Read the report

You get a summary containing:

• A hardening score out of 100
• A severity breakdown: how many HIGH, MEDIUM and LOW findings
• Pass, warning, failed and skipped counts
• A findings table naming the specific log files, their permissions and their sizes

Step 5: Fix what failed

Select the failed findings and send them to the AI Terminal. Each proposed fix command appears with an explanation of what it changes. Nothing runs until you review and approve it, which matters here because a chown across a log directory while the server holds those files open is a change worth reading before it runs.

Step 6: Re-run and compare

Run the same audit again after applying the fixes and watch the score move. Check 4 is the one to re-run after any rotation change, because the failure mode is silent: the config looks right, rotation runs, and the new log stays empty.

Conclusion

Nothing on this page stops an attack. What it decides is whether, on the morning after one, you can say what happened. An access log that was switched off for one route, a rotated file the server never reopened, a permissions change that let every local account read your URLs: each is invisible right up to the moment it is the only thing you needed.

The fifth check is the exception, and it draws a line worth remembering: Fail2Ban reacts to a request that has already been served, a WAF refuses one before it is handled. The CtrlOps Security Audit runs all 5 in about 12 seconds per server.

The neighbouring checklists cover the other web server layers: security headers, TLS configuration, content exposure, configuration hardening and identification and patching.

Frequently asked questions