# GoAccess cPanel: AWStats and Webalizer Replacement Before 140

Source: https://srvscripts.com/guides/goaccess-cpanel-awstats-replacement/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

AWStats, Webalizer and Analog have shipped with cPanel for two decades, and they are all being removed in the 140 tier once the GoAccess integration is in place. Webalizer stopped receiving upstream updates years ago, AWStats needs Perl CGI and a sizeable daily processing job, and none of them understand modern log formats well. GoAccess is a fast C-based analyser that produces an interactive HTML report from the same domlogs, in a fraction of the time. If you run 136 or 138 today, you can install GoAccess now, run it in parallel, and remove the dependency on the old tools before the update forces the issue.

In short: Install GoAccess from EPEL with dnf install epel-release goaccess, run it against /etc/apache2/logs/domlogs/<domain> with –log-format=COMBINED and write the HTML report under each user’s ~/tmp/goaccess/, then schedule that for every…

**Short answer:** Install GoAccess from EPEL with `dnf install epel-release goaccess`, run it against `/etc/apache2/logs/domlogs/<domain>` with `--log-format=COMBINED` and write the HTML report under each user’s `~/tmp/goaccess/`, then schedule that for every account from `/etc/cron.daily` before cpanellogd truncates the logs. Once the reports match AWStats for a day, disable AWStats and Webalizer in WHM » Statistics Software Configuration so the 140 update changes nothing.

## What is actually changing

On the 140 EDGE tier the three legacy analysers are removed from the cPanel distribution. The **Metrics** section in cPanel loses the AWStats, Webalizer and Analog icons; bandwidth accounting is not affected because it is done by cpanellogd independently of the report generators. Existing report data in `~/tmp/awstats` and `~/tmp/webalizer` is not deleted by the update, but nothing will regenerate it. Check the release notes for your build to see whether GoAccess is already exposed in the cPanel interface, because the exact landing build changed during the 140 development cycle.

If your servers are on LTS 134 they will not see this until they move to a later LTS, but customers who move between your servers will notice differences, so it is worth standardising early.

## Install GoAccess on the server

GoAccess is packaged in EPEL for AlmaLinux 8, 9 and 10, and in the Ubuntu 22.04 and 24.04 archives. On AlmaLinux:

```
dnf install epel-release -y
dnf install goaccess -y
goaccess --version
```

The EPEL build is usually a version or two behind upstream but supports real-time HTML output and GeoIP if you add a database. On Ubuntu use `apt install goaccess`. Once cPanel ships its own `ea-goaccess` or equivalent package, prefer that over EPEL so the two do not conflict; check `rpm -qa | grep -i goaccess` after the 140 update.

## Generate a report for one domain

cPanel’s domlogs are in Apache combined format with a small twist: the vhost files under `/etc/apache2/logs/domlogs/` do not include the vhost name, so use the `COMBINED` preset:

```
goaccess /etc/apache2/logs/domlogs/example.com \
  --log-format=COMBINED \
  -o /home/USER/public_html/stats/report.html
```

For the SSL log, the file is `example.com-ssl_log` in the same directory. To combine both:

```
cat /etc/apache2/logs/domlogs/example.com /etc/apache2/logs/domlogs/example.com-ssl_log \
  | goaccess --log-format=COMBINED -o /home/USER/tmp/goaccess/example.com.html -
```

Do not write reports into `public_html` on a customer site without password protection; a stats page reveals URLs, referrers and IP addresses. Put them under `~/tmp/goaccess/` and expose them through a protected directory or a small cPanel plugin page instead.

## Run it for every account on a schedule

Until the native integration lands, a cron job is the practical approach. This script walks every account, finds its domains, and writes one report per domain into the user’s home with correct ownership:

```
#!/bin/bash
for user in $(ls /var/cpanel/users); do
  home=$(getent passwd "$user" | cut -d: -f6)
  [ -d "$home" ] || continue
  mkdir -p "$home/tmp/goaccess"
  for dom in $(grep -E '^DNS[0-9]*=' /var/cpanel/users/$user | cut -d= -f2); do
    logs=$(ls /etc/apache2/logs/domlogs/$dom /etc/apache2/logs/domlogs/$dom-ssl_log 2>/dev/null)
    [ -n "$logs" ] || continue
    cat $logs | goaccess --log-format=COMBINED -o "$home/tmp/goaccess/$dom.html" - 2>/dev/null
  done
  chown -R "$user:$user" "$home/tmp/goaccess"
done
```

Run it from `/etc/cron.daily` before cpanellogd’s processing hour, because if you have “delete access logs after stats” enabled the domlogs are truncated afterwards. GoAccess only sees what is in the file when it runs; for historical reports, feed it the gzipped archives from `~/logs/` as well using `zcat`.

A common pitfall is CageFS on CloudLinux: if you later let users run GoAccess themselves, add it to the CageFS skeleton with `cagefsctl --addrpm goaccess` and update the cage.

## Prepare customers

Most customers use the stats icons rarely, but the ones who do (agencies reporting to their own clients, for example) will notice. Before your servers move to 140:

- Send a notice explaining that AWStats and Webalizer are being retired by the vendor and pointing to the new report location.

- Export the AWStats history for anyone who asks: the monthly data files in `~/tmp/awstats/awstats*.txt` are plain text and can be archived.

- Offer a hosted analytics alternative (Matomo, Plausible or a similar self-hosted tool) for customers who want long-term trends, since GoAccess is a log analyser and does not keep a database across runs unless you use its persistence options.

## Verify

Open a generated report in a browser and confirm the visitor count roughly matches what AWStats reported for the same day; small differences are expected because the two tools count bots differently. Check `ls -la /home/*/tmp/goaccess/` after the first cron run to confirm ownership and that every active domain has a file. Time the run with `time /etc/cron.daily/goaccess-reports` and compare it with the AWStats processing time in `/usr/local/cpanel/logs/cpanellogd.log`; on most servers GoAccess finishes in under a tenth of the time. Once you are satisfied, disable AWStats and Webalizer under **WHM » Statistics Software Configuration** so the daily run stops doing redundant work, and the 140 update becomes a non-event.

## GoAccess cPanel at a glance

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

**Related guides:** [“cPanel license is invalid”: troubleshooting manage2, IP changes and firewalls](https://srvscripts.com/guides/cpanel-license-is-invalid/) · [cPanel 2026 pricing and licensing explained: Solo, Admin, Pro, Premier and WP Squared](https://srvscripts.com/guides/cpanel-pricing-2026-licensing/) · [Account quotas show “unlimited”: fixquotas and XFS/ext4 quota repair on cPanel](https://srvscripts.com/guides/cpanel-quotas-unlimited-fixquotas/).

## Frequently asked questions

### Does removing AWStats and Webalizer affect bandwidth usage in cPanel?

No. Bandwidth accounting is done by cpanellogd independently of the report generators, so account bandwidth graphs, quotas and overage notices continue to work after the analysers are gone.

### Can customers still see their old AWStats history after cPanel 140?

The data files under `~/tmp/awstats/` are not deleted by the update, but nothing regenerates them and the viewer icon disappears. Export the monthly `awstats*.txt` files for customers who need the history before the server moves to 140.

### Is GoAccess free to use on a cPanel server?

Yes. GoAccess is open source and packaged in EPEL and the Ubuntu archives, and cPanel’s own integration in 140 ships as part of the standard distribution with no additional licence.