Apache HTTP Server course

Apache Access and Error Logs: Locations, Formats, and Log Levels

Learn where Apache access and error logs are stored, how to read entries, configure per-site destinations, control LogLevel, and troubleshoot common HTTP failures.

Apache logging provides two complementary views of web-server activity. The access log records incoming HTTP requests and the responses Apache sends. The error log records diagnostic information such as warnings, configuration problems, startup failures, and request-processing errors.

Use the access log to answer what request happened and what status did Apache return? Use the error log to investigate why did Apache produce that result? Together, these logs help with troubleshooting, service monitoring, security investigations, and operational reporting.

Apache Log Types and Default Locations

On Debian and Ubuntu installations, the usual global log files are /var/log/apache2/access.log and /var/log/apache2/error.log. These are common defaults, not guarantees. Locations can change with the operating system, installation method, global configuration, or individual virtual-host configuration.

What the Access Log Records

An access log is Apache’s request or transfer record. Normally, each HTTP request handled by a virtual host produces one access-log entry. The entry shows the apparent client, time, requested resource, response status, response size, and often the referrer and user-agent.

The client address is the source address Apache sees on the connection. If a reverse proxy or load balancer connects to Apache, this address may identify the proxy rather than the original visitor unless forwarded-client information is configured and handled appropriately.

Combined Log Format

A common layout is the combined log format. It adds the referring page and user-agent to the basic request record. An illustrative entry is:

203.0.113.42 - - [17/Aug/2026:10:15:32 +0000] "GET /list.html HTTP/1.1" 200 4821 "https://example.test/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 Chrome/140.0.0.0 Safari/537.36"

The request line contains three parts: the HTTP method, such as GET or POST; the requested URI, including the path and possibly a query string; and the HTTP protocol version, such as HTTP/1.1 or HTTP/2.0.

Status-code families provide a quick summary:

• 2xx: the request succeeded, such as 200.
• 3xx: Apache directed the client elsewhere, such as with 301 or 302.
• 4xx: the request was invalid, missing, unauthorized, or denied from the client-facing perspective, such as 404 or 403.
• 5xx: Apache or an upstream service could not successfully process the request, such as 500, 502, or 503.

A hyphen generally means that a value was unavailable or was not recorded. Referrers and user-agents are supplied by clients and can be omitted or falsified.

Successful Request Example

In the example above, the apparent client 203.0.113.42 requested /list.html with GET over HTTP/1.1 at the recorded time. Apache returned status 200 and 4,821 response bytes. The referrer suggests the visitor came from the site root, and the user-agent resembles a Chrome browser on Linux. This tells you what happened, but not necessarily who the person was.

What the Error Log Records

The error log is Apache’s diagnostic record. It can contain errors, warnings, startup and shutdown messages, module failures, configuration problems, permission failures, and details about request-processing failures.

It is a primary diagnostic source when Apache will not start, a configuration test or reload fails, TLS setup fails, a module cannot load, permissions prevent file access, or a request returns a server-side error.

An error entry commonly contains a timestamp, severity, process or thread context, and a message. Depending on the event and configuration, it may also include a client address, virtual host, request path, or module name.

[Mon Aug 17 10:16:04.123456 2026] [authz_core:error] [pid 1842:tid 1401] [client 203.0.113.42:51822] AH01630: client denied by server configuration: /var/www/example/private

The access log might show the resulting 403, while this error-log entry explains that authorization rules denied access to the resource.

Configuring Log Destinations

Log destinations can be defined globally or separately inside a virtual host. A virtual host is an Apache configuration block containing settings for a particular site, domain, address, or port. Separate files make it easier to isolate requests and failures when one server hosts several domains.

Standard Apache syntax for a dedicated site is:

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

    CustomLog /var/log/apache2/example-access.log combined
    ErrorLog /var/log/apache2/example-error.log
    LogLevel warn
</VirtualHost>

CustomLog selects the access-log destination and format. ErrorLog selects the diagnostic-log destination. The final word combined refers to a configured log format that includes referrer and user-agent fields.

Some environments integrate Apache with system logging instead of, or in addition to, ordinary files. File destinations are often simplest to inspect, but whichever destination you choose must be available to the Apache service. The parent directory must exist, and its ownership and permissions must allow Apache to create or append the log file without exposing it to unauthorized users.

LogLevel and Error Severity

LogLevel sets the minimum severity of diagnostic messages written to the error log. A severity threshold keeps messages at the selected level and at more severe levels.

The levels below are ordered from most severe to most verbose:

For example, LogLevel warn records warnings and more severe messages. LogLevel info also records notice and informational messages. LogLevel debug can generate large volumes of data, increase disk consumption, affect performance, and collect more sensitive operational details.

A global setting can be placed in the main Apache configuration:

LogLevel warn

A virtual host can use a more specific setting:

<VirtualHost *:80>
    ServerName example.test
    CustomLog /var/log/apache2/example-access.log combined
    ErrorLog /var/log/apache2/example-error.log
    LogLevel info
</VirtualHost>

Increase verbosity only for the period needed to reproduce a problem. After collecting evidence, restore an appropriate production level and confirm that log rotation and retention remain adequate.

Safe Log Inspection Workflow

Inspect logs without editing them, and correlate entries by timestamp, virtual host, request path, and status code.

1. Reproduce the problem and note the exact time, URL, HTTP method, hostname, and client-visible status.
2. View recent access records:

   sudo tail -n 50 /var/log/apache2/access.log

3. Follow diagnostic messages while reproducing the issue:

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

4. Search for a path, status, or distinctive message:

   sudo grep '/list.html' /var/log/apache2/access.log
   sudo grep '" 5[0-9][0-9] ' /var/log/apache2/access.log

5. Match the failed access-log request with nearby error-log entries. The access record identifies the outcome; the error log may identify the underlying configuration, permission, routing, upstream, or application problem.

Before applying logging changes, validate the Apache configuration:

sudo apachectl configtest

Only after a successful test should you reload the service:

sudo systemctl reload apache2

A reload usually applies configuration changes without dropping existing connections. If the configuration test reports an error, correct it before attempting a reload or restart.

Practical Troubleshooting Examples

Missing Page: HTTP 404

Start with the access log and find the requested path. Confirm that the entry has status 404. Check capitalization, trailing slashes, hostname, query string, document root, aliases, rewrite rules, and application routes. If Apache reports a file-system or routing detail, inspect the corresponding error-log messages.

Server-Side Failure: HTTP 500, 502, or 503

Use the access log to identify the exact timestamp, path, and status. Then inspect the error log around that time. A 500 may relate to an application handler, invalid directive, missing file, or permission problem. A 502 or 503 often requires checking the reverse-proxy or upstream service as well as Apache’s diagnostic message.

Unexpected Redirects

Look for repeated 3xx responses in the access log and compare the requested paths and hostnames. Then review virtual-host selection, rewrite rules, HTTP-to-HTTPS configuration, and application routing. The access log shows the redirect result; configuration and error messages may explain why it was generated.

Permission Denied

An access entry may show 403, while the error log may say that access was denied or that Apache could not read a file. Check directory traversal permissions, file ownership, access-control directives, security modules, and the configured document root.

TLS Failure

Check the error log first for certificate, key, protocol, module, or virtual-host binding messages. For a client-visible request failure, correlate the event with access records and verify that the intended TLS virtual host and certificate configuration are active.

Apache Will Not Start or Reload

Run the configuration test before changing the service state. Read recent error-log entries for the file name, line number, directive, missing module, invalid syntax, permission issue, or unavailable port. Correct the reported problem and run the test again before reloading.

Configured Logs Are Empty or Cannot Be Opened

Confirm that the configured path is correct and that its parent directory exists. Check ownership and permissions on the directory and file, and ensure that the Apache service account can append to the destination. Validate the configuration and reload Apache after correcting the file-system state.

Log Rotation, Privacy, and Storage

Logs grow continuously. Use log rotation to archive, compress, replace, and eventually remove old files so disk usage does not grow without limit. Verify that the operating system’s rotation policy is active and that retention matches operational and legal requirements.

Access and error logs may contain potentially sensitive operational data, including IP addresses, full URLs, query strings, referrers, and client identifiers. Restrict file permissions, protect backups, define a sensible retention period, and avoid unnecessary verbose logging. Debug output should be temporary because it can increase disk use, reduce performance, and reveal details that are not needed in normal operation.

Quick Reference: Symptom and First Log to Check

Key Points

• The access log describes incoming requests and their outcomes.
• The error log supplies diagnostic context for startup, configuration, permission, module, TLS, and runtime problems.
• Use timestamps and request paths to correlate one log with the other.
• Global settings apply broadly; virtual-host log files isolate sites and simplify investigation.
• Use CustomLog for standard Apache access-log output, ErrorLog for diagnostics, and LogLevel for diagnostic severity.
• Validate configuration before reloading, and reduce temporary verbose logging after diagnosis.
• Protect, rotate, and retain logs deliberately because they grow continuously and may contain sensitive data.

For related Apache administration topics, see Create New Virtual Host, Configuration Files, Configure SSL, Configure Apache as a Reverse Proxy, and Display Server Statistics.