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

Source: https://srvscripts.com/guides/cpanel-apache-log-retention/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

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.

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)…

**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](/scripts/cpanel-disk-usage-report/) and the [disk-full guide](/guides/cpanel-disk-full-cleanup/) 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

**Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [What changed in cPanel 138: Meridian, Ask AI, Nova, MCP and domain rename](https://srvscripts.com/guides/what-changed-in-cpanel-138/) · [Install ImageMagick and PHP Imagick for EA-PHP on AlmaLinux 8/9/10 (and CloudLinux CageFS)](https://srvscripts.com/guides/install-imagick-ea-php-almalinux/) · [Ubuntu 24.04 or AlmaLinux 9/10 for a new cPanel server in 2026?](https://srvscripts.com/guides/ubuntu-vs-almalinux-cpanel/).

## 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.