← Back to Apache Course | Chapter 6: Logging | Lesson 2 of 4

Error Log

The error log records problems -- module load failures, crashed scripts, permission errors, and Apache's own startup messages -- separately from ordinary traffic, so you can find out *why* something broke instead of just that it did.

Where It Lives

The default error log is /var/log/apache2/error.log on Ubuntu/Debian and /var/log/httpd/error_log on RHEL-family systems. As with the access log, individual VirtualHosts can (and should, for anything beyond a single-site server) define their own with ErrorLog.

LogLevel

LogLevel controls how much detail gets written, from least to most verbose: emerg, alert, crit, error, warn, notice, info, debug. The default warn is a reasonable baseline for production; debug is far noisier and mainly useful while actively troubleshooting a specific problem, then turned back down afterward.

What You'll Actually See There

Startup problems (a config syntax error, a module that failed to load, a port already in use), permission errors (Apache's user can't read a file it's been asked to serve), PHP fatal errors and stack traces (if display_errors is off, as it should be in production, this is the *only* place they're visible), and mod_rewrite's own rewrite-log-equivalent debug output when LogLevel includes rewrite:trace all end up here.

Note: When something works in the browser but with an unexpected 500 error and no clue why, tail -f the error log and reload the page -- the real underlying error is almost always sitting right there.

Using the Error Log to Debug a Config Change

If systemctl restart apache2 fails, systemctl status apache2 often shows only a truncated summary -- the full detail (which directive, which file, which line) is almost always in the error log's most recent lines, which is why checking it is usually the very next step after a failed restart.

Example: Per-site error log and LogLevel

apacheconf
<VirtualHost *:80>
    ServerName example.com
    ErrorLog /var/log/apache2/example.com-error.log
    LogLevel warn
</VirtualHost>
{# Flagged by hand after confirming a runner can't handle this example (a shell command / go.mod file stored as a TopicExample, a language feature the configured runner version doesn't support, or output that blows a runner's sandbox limit) -- see TopicExample.norun. Never render the run button for these, regardless of language, since it would just fail at execute_code (or worse, hang the Judge0 queue on a submission that can never finish cleanly). #}

⚠️ This example can't run in the browser editor. Try it in your own local environment instead.

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Only checking systemctl status after a failed restart and stopping there, missing the more detailed explanation waiting in the error log.
  2. Running production with LogLevel debug left on indefinitely, generating far more noise than needed and making the log harder to scan for real problems.
  3. Not realizing PHP/application errors with display_errors off (correct for production) still land in the error log -- they're just invisible in the browser, not gone entirely.
🔒

Chapter Quiz — Complete all 4 topics to unlock

0/4 topics done

Complete these topics first:

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.