Offensive Security Researcher & Quantum Cryptography Analyst

How to Set Up Apache Error Logs

Abdul Wahab Junaid
How to set up Apache error logs

How to set up Apache error logs

If you run a website on Apache, sooner or later something is going to break. A plugin will throw a fatal error, a permissions issue will block a script from running, or a misconfigured virtual host will start returning 500 errors out of nowhere. When that happens, the first place I go is the Apache error log. I’ve been managing Apache servers for years now, and I can tell you that a well-configured error log has saved me more debugging time than almost any other tool in my sysadmin toolkit.

What Is the Apache Error Log and Why Does It Matter

The Apache error log is where the web server writes down everything that goes wrong (and a lot of things that go right, depending on your log level). This includes server startup and shutdown messages, module loading issues, PHP or CGI errors, permission denials, and any warnings the server generates while processing requests.

Unlike the access log, which just records who requested what and when, the error log tells you why something failed. If I had to pick one log file to keep an eye on when a site goes down, it would always be this one.

Prerequisites

Before diving in, here’s what I assume you already have in place:

If you haven’t installed Apache yet, a quick sudo apt install apache2 (Debian-based) or sudo dnf install httpd (RHEL-based) will get you there.

Where Apache Error Logs Live by Default

The default location depends on your distribution:

You can always confirm the active path by checking your main configuration file:

# Debian/Ubuntu
grep -r "ErrorLog" /etc/apache2/

# CentOS/RHEL
grep -r "ErrorLog" /etc/httpd/

Basic Error Log Configuration

The core directive you need is ErrorLog. It’s usually set in the main config file (apache2.conf or httpd.conf) and can be overridden per virtual host.

ErrorLog ${APACHE_LOG_DIR}/error.log

On CentOS, you’ll see something closer to:

ErrorLog "logs/error_log"

I always recommend keeping this directive explicit rather than relying purely on defaults, especially once you start managing multiple sites on one server.

Setting the Log Level

Apache lets you control how verbose the error log is with the LogLevel directive. The levels, from least to most verbose, are:

emerg -> alert -> crit -> error -> warn -> notice -> info -> debug -> trace1-8

In production, I stick with warn most of the time:

LogLevel warn

When I’m actively debugging something, I’ll temporarily bump it up:

LogLevel debug

Just remember to set it back afterward — debug and trace levels generate a lot of noise and can bloat your logs fast.

Module-Specific Log Levels

One trick I use often is setting a different log level for a specific module. For example, if I only want verbose logging from mod_rewrite while troubleshooting redirect rules:

LogLevel warn rewrite:trace3

This keeps the rest of the server quiet while giving me detailed rewrite debugging.

Per-Virtual-Host Error Logs

If you’re hosting multiple sites on one server (which is almost always the case for me), you’ll want a separate error log per virtual host. This makes troubleshooting dramatically easier because you’re not sifting through unrelated traffic from other domains.

Here’s a typical virtual host block:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com/public_html

    ErrorLog /var/log/apache2/example.com-error.log
    LogLevel warn

    CustomLog /var/log/apache2/example.com-access.log combined
</VirtualHost>

I do this for every domain I host. It takes an extra thirty seconds per site and pays off enormously the first time something breaks.

Reloading Apache After Changes

Any time you edit the config, you need to test and reload:

# Test configuration syntax
sudo apachectl configtest
# or
sudo apache2ctl configtest

# Reload gracefully (no dropped connections)
sudo systemctl reload apache2   # Debian/Ubuntu
sudo systemctl reload httpd     # CentOS/RHEL

I never skip the configtest step. A typo in your ErrorLog path can prevent Apache from starting entirely, and that’s a bad way to find out you made a mistake.

Reading and Filtering the Error Log

Once logging is set up, here’s how I actually use it day to day.

Tailing in Real Time

sudo tail -f /var/log/apache2/error.log

I keep this running in a terminal tab whenever I’m deploying changes or testing a new feature.

Searching for Specific Errors

grep -i "permission denied" /var/log/apache2/error.log
grep -i "php fatal" /var/log/apache2/error.log

Counting Error Frequency

awk '{print $9}' /var/log/apache2/error.log | sort | uniq -c | sort -nr

This kind of quick frequency count is often how I spot a recurring issue before it becomes a major outage.

Log Rotation

Left unmanaged, error logs will grow forever and eventually fill your disk. Both major distros ship with logrotate pre-configured for Apache, but it’s worth checking the config:

cat /etc/logrotate.d/apache2   # Debian/Ubuntu
cat /etc/logrotate.d/httpd     # CentOS/RHEL

A typical rotation config looks like this:

/var/log/apache2/*.log {
    weekly
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        systemctl reload apache2 > /dev/null
    endscript
}

I usually adjust rotate to keep 30 days of logs instead of 14, since I’ve needed to go back further than two weeks more than once while investigating an intermittent bug.

Real-World Use Cases

Here are a few scenarios where the error log has directly saved me:

Troubleshooting Tips

Common Mistakes to Avoid

  1. Leaving LogLevel debug on in production. It fills disks fast and can leak sensitive info into logs.
  2. Sharing one error log across all virtual hosts. This makes debugging a specific site painful.
  3. Forgetting to run configtest before reloading. A bad ErrorLog path can stop Apache from starting.
  4. Not rotating logs at all. I’ve seen a /var partition fill up completely because of this.
  5. Ignoring warnings. A warn-level message today is often an error-level outage tomorrow.

Security Best Practices

Performance Optimization

Frequently Asked Questions

Q: Where is the Apache error log located by default? A: On Debian/Ubuntu it’s /var/log/apache2/error.log; on CentOS/RHEL it’s /var/log/httpd/error_log.

Q: How do I change the error log location? A: Edit the ErrorLog directive in your main config or virtual host block, then run apachectl configtest and reload Apache.

Q: What’s the difference between the error log and access log? A: The access log records every request (who, what, when, response code). The error log records problems — warnings, failures, and diagnostic messages.

Q: How do I stop my error log from growing too large? A: Set up logrotate (usually already configured) and keep LogLevel at a reasonable level like warn instead of debug.

Q: Can I have different log levels for different modules? A: Yes — use syntax like LogLevel warn rewrite:trace3 to set a module-specific level alongside your global level.

Summary and Key Takeaways

Setting up Apache error logs properly is one of those unglamorous tasks that pays off every single time something breaks. To recap what I covered:

A little discipline here means that when something does go wrong — and it will — you’ll have exactly the information you need to fix it fast.

References

Exit mobile version