cPanel Apache Log Retention (v136+): Stop Disk Bloat

How cPanel 136 and later handle Apache access and error log rotation, the new retention scripts, cpanellogd archiving per account, and the safe way to reclaim disk from oversized domlogs without breaking AWStats or bandwidth accounting.

Published 29 Sep 2026Updated 3 Oct 2026 6 min read By srvScripts team

Apache logs are the quiet disk consumer on most cPanel servers. Per-domain access logs in /etc/apache2/logs/domlogs grow with traffic, bot storms can add gigabytes in a day, and the global error_log has no size cap by default. cPanel 136 added retention scripts that make cleanup a policy rather than an emergency, but they need to be turned on and understood. This guide explains where the logs live, how the pieces interact, and how to set a retention policy that survives updates.

Short answer: Per-domain logs in /etc/apache2/logs/domlogs are handled by cpanellogd, so enable Delete each domain’s access logs after stats run and archive-and-prune in Tweak Settings » Stats and Logs (whmapi1 set_tweaksetting key=dumplogs value=1), then set a day and size limit in the 136+ Log Retention settings. The global access_log and error_log are rotated by logrotate through /etc/logrotate.d/httpd, so give them a size trigger. In an emergency truncate an oversized log with : > file rather than deleting it.

Know which process owns which log

There are three separate mechanisms and they are often confused:

Apache itself writes /etc/apache2/logs/access_log and error_log (global) plus one file per vhost in /etc/apache2/logs/domlogs/. Apache never rotates these; something else must.
cpanellogd runs on a schedule (default daily at the bandwidth processing hour), reads each domlog to compute bandwidth and run AWStats/Webalizer, then optionally archives the log into the user’s ~/logs/ directory as a gzip and truncates the live file.
logrotate handles the global access_log and error_log via /etc/logrotate.d/httpd (installed by EasyApache), plus the cPanel service logs under /usr/local/cpanel/logs/.

If per-domain logs are huge, cpanellogd is misconfigured or not running. If the global error log is huge, logrotate is the fix.

Configure per-account archiving

Under WHM » Service Configuration » cPanel Log Rotation Configuration, you control which cPanel service logs are rotated by logrotate and at what size (default 300 MB). That is for cPanel’s own logs, not Apache.

Per-account domlog behaviour is under WHM » Server Configuration » Tweak Settings » Stats and Logs:

Delete each domain’s access logs after stats run — the setting most admins want on a busy shared server. cpanellogd truncates the domlog after processing.
Archive logs in user’s home directory — users can enable this in cPanel » Metrics » Raw Access; you can force the default.
Remove archived logs from the previous month — pairs with the above so ~/logs does not grow forever.

From the CLI:

whmapi1 set_tweaksetting key=dumplogs value=1
whmapi1 set_tweaksetting key=default_archive_logs value=1
whmapi1 set_tweaksetting key=default_remove_old_archived_logs value=1

Note that “delete after stats” means the raw log is gone once bandwidth has been counted. If you rely on raw logs for abuse investigations, keep archiving on and set a retention period in the user’s home instead.

Use the 136 retention scripts

Version 136 introduced a retention workflow so log cleanup no longer depends on remembering tweak settings. The relevant tooling lives under /usr/local/cpanel/scripts/ and /usr/local/cpanel/bin/; the exact script names differ slightly between 136 and 138 builds, so list them:

ls /usr/local/cpanel/scripts/ | grep -i -E 'log|retention'

The retention configuration is exposed in WHM » Service Configuration » Apache Configuration » Log Retention on 138 (on 136 look under Tweak Settings » Stats and Logs). You set a number of days to keep archived domlogs and a maximum total size; the daily maintenance run then prunes oldest-first. Set it to something like 30 days and 20 GB on a typical shared box. Check the changelog for your build if the option is not where you expect; this area moved between 136.0.x builds.

A common pitfall is enabling retention but leaving cpanellogd disabled in WHM » Service Manager. Nothing then processes the domlogs, the retention script has nothing to prune, and the live logs keep growing. Confirm it is enabled and check its last run in /usr/local/cpanel/logs/cpanellogd.log.

Rotate the global Apache logs

EasyApache’s logrotate config rotates the global logs weekly by default, which is too slow for a busy server. Edit /etc/logrotate.d/httpd or drop an override:

/etc/apache2/logs/access_log /etc/apache2/logs/error_log /etc/apache2/logs/suexec_log {
    size 200M
    rotate 4
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/sbin/apachectl graceful > /dev/null 2>&1 || true
    endscript
}

Test it with logrotate -d /etc/logrotate.d/httpd (dry run) and force one rotation with logrotate -f /etc/logrotate.d/httpd. Keep the file under EasyApache’s management: it is regenerated on some EA4 updates, so if you customise it, copy your version to /etc/logrotate.d/httpd-local with a distinct path list, or use the Apache log include mechanism.

Reclaim space in an emergency

When a server is already at 100% because of one domlog, do not rm the file; Apache keeps the inode open and the space is not released until restart. Truncate instead:

du -sh /etc/apache2/logs/domlogs/* | sort -rh | head
: > /etc/apache2/logs/domlogs/example.com

Truncating loses the bandwidth data cpanellogd has not yet processed, so run /scripts/runweblogs USERNAME first if the account’s stats matter. For a global error log that has filled the disk with PHP warnings from one site, truncate the same way and then fix the site or lower its log_errors setting; a 20 GB error log is always a symptom. Our disk usage report script and the disk-full guide cover the broader cleanup.

Verify

After setting the policy, wait for one cpanellogd cycle and check:

ls -la /etc/apache2/logs/domlogs/ | sort -k5 -n | tail shows no domlog older than a day for accounts with delete-after-stats enabled.
du -sh /home/*/logs 2>/dev/null | sort -rh | head shows archives bounded by your retention period.
ls -la /etc/apache2/logs/ shows access_log.1.gz and friends at the expected size.
whmapi1 get_tweaksetting key=dumplogs returns 1.

Set a disk usage alert at 80% in WHM » Contact Manager or your monitoring so log growth becomes a ticket rather than an outage.

CPanel Apache log retention at a glance

cPanel Apache Log Retention summary card: Per-domain logs in /etc/apache2/logs/domlogs are handled by cpanellogd, so enable Delete each domain's access logs… — In short: Per-domain logs in /etc/apache2/logs/domlogs are handled by cpanellogd, so enable Delete each domain’s access logs after stats run and archive-and-prune in Tweak Settings » Stats and Logs (whmapi1 set_tweaksetting key=dumplogs value=1)…

Official documentation: cPanel & WHM documentation, Linux man pages.

Frequently asked questions

Does deleting domlogs after stats run break bandwidth accounting or AWStats?

No. cpanellogd processes each domlog for bandwidth and statistics before truncating it, so the figures are recorded first; only a manual truncation before the run loses unprocessed data.

How long are archived Apache logs kept under the user’s home directory?

By default archives accumulate in ~/logs until the option to remove the previous month’s archives is enabled; with the 136 retention settings you choose a number of days and a total size, and the daily run prunes oldest-first.

Can I recover space from a huge domlog without restarting Apache?

Yes. Truncate the file in place with : > /etc/apache2/logs/domlogs/example.com; deleting it instead leaves the inode open and the space is not freed until Apache restarts.