VMware ESXi and vSphere Cluster Management

Apache Access and Error Logs: access.log and error.log

Learn where Apache access.log and error.log are stored, how to read entries, configure log destinations and levels, troubleshoot failures, and manage log rotation.

Apache logging records what the web server receives, how it responds, and which problems occur while handling requests. The two logs you will use most often are access.log, also called the transfer log, and error.log, the diagnostic log.

On Debian- and Ubuntu-style installations, these files are commonly stored at /var/log/apache2/access.log and /var/log/apache2/error.log. The exact locations depend on the operating system package, Apache configuration, and virtual-host setup.

Why Apache logs matter

Logs provide a chronological record of server activity. They are useful for:

  • Monitoring: measuring requests, response statuses, traffic volume, and unusual activity.
  • Troubleshooting: finding configuration, permission, module, proxy, SSL, and application-related failures.
  • Security review: identifying repeated login attempts, scanning, unexpected clients, suspicious URLs, and error patterns.
  • Understanding client activity: seeing which URLs were requested, which responses were returned, and what client software made the requests.

Access logging describes request and transfer activity. Error logging describes diagnostic events during startup and request processing. During an investigation, consult both: the access log shows what response occurred, while the error log often explains why it occurred.

Apache log files at a glance

Log filePrimary purposeTypical Debian/Ubuntu pathBest used for
access.logAccess or transfer log containing handled requests/var/log/apache2/access.logClient activity, URLs, methods, statuses, response sizes, and traffic analysis
error.logDiagnostic log containing startup, configuration, module, and request-processing messages/var/log/apache2/error.logFinding the reason for startup failures, errors, permission problems, and unexpected responses

Paths vary between operating systems, distributions, packages, and configurations. A virtual host can write to its own access and error files instead of using one shared file.

Finding and inspecting the default logs

Reading system logs usually requires elevated permissions:

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

To watch new entries as requests arrive, open a terminal for each log:

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

Make a test request in a browser or with a command-line HTTP client, then compare the new entries. Use the request time, URL, status, and client information to connect activity in the two files.

Reading an access.log entry

The exact access-log layout is controlled by the Apache LogFormat directive. A common combined-format entry might look like this:

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

This request can be read from left to right:

FieldExample valueMeaningTroubleshooting use
Client IP address203.0.113.42Source address recorded for the requestIdentify a requesting host or group requests by client; proxy configuration can affect which address appears
Identity field-Usually unused in modern configurationsNormally ignored unless identity logging is configured
Authenticated user-Authenticated username, if HTTP authentication is usedDetermine which authenticated account made a request
Timestamp[18/Aug/2026:14:32:10 +0000]Request date, time, and timezoneCorrelate the request with error-log entries and application logs
Request method and URLGET /list.htmlHTTP method and requested pathFind missing pages, unexpected methods, or suspicious URLs
ProtocolHTTP/1.1HTTP protocol version used by the clientUnderstand protocol-specific behavior
Status code200Numeric result returned by Apache or an upstream applicationClassify success, redirect, client error, or server error
Response size4821Response body size in bytes, depending on format and responseSpot unusually large or empty responses
Referrerhttps://example.com/Page that linked to the requested resource, when suppliedTrace navigation and broken links; clients can omit or forge it
User-agentMozilla/5.0 ... Linux ... Chrome/140.0Client-provided browser, application, and often operating-system informationCompare browser behavior and identify automated clients; it is not trustworthy identity proof

In this example, client 203.0.113.42 used GET to request /list.html over HTTP/1.1. Apache returned status 200, indicating success, with a response body of 4,821 bytes. The user-agent suggests a Chrome-based browser running on Linux.

Common access-log status codes

StatusCategoryInterpretationNext log to inspect
200Successful responseThe request completed successfullyUsually access.log is sufficient unless behavior is unexpected
301 or 302RedirectThe client was directed to another URLCheck redirect rules and then follow the target request
403Client errorAccess was forbiddenCheck error.log for authorization, directory, or permission details
404Client errorThe requested resource was not foundCheck URL mapping, rewrites, aliases, document-root files, and error.log
500Server errorThe server or application failed while handling the requestInspect error.log at the matching time
502 or 503Server or gateway errorAn upstream or service dependency failed or was unavailableInspect error.log and the upstream application's logs

Reading an error.log entry

An error-log line commonly contains a timestamp, the source module, severity, process or thread information when available, request or client context, and a diagnostic message. For example:

[Tue Aug 18 14:35:07.123456 2026] [proxy:error] [pid 2148:tid 2152] [client 203.0.113.42:53144] AH00898: Error reading from remote server returned by /app/list
  • Timestamp: identifies when the event occurred, including subsecond detail in some formats.
  • Module or source: proxy indicates the proxy subsystem reported the event.
  • Severity: error indicates a failure that should be investigated.
  • Process and thread: pid and tid help identify the Apache worker involved when those values are available.
  • Client context: the client address and port can connect the diagnostic message to an access request.
  • Message: the actionable description, here indicating a problem reading from an upstream server.

Error entries also report Apache startup failures, invalid directives, missing modules, file and directory permission problems, SSL/TLS issues, rewrite failures, proxy problems, and request-processing errors. If Apache will not start, check error.log first. If a site returns an unexpected failure, find the access-log status and then inspect error.log at the same time.

Configuring log destinations and formats

ErrorLog selects the destination for diagnostic messages. CustomLog selects the destination and access-log format. LogFormat defines the layout used by a named access format.

These directives can be placed in global Apache configuration or inside a VirtualHost block. A VirtualHost is the configuration context for a particular site, hostname, address, or port.

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog /var/log/apache2/access.log common

For multiple sites, separate files make investigations clearer because unrelated traffic is not mixed:

<VirtualHost *:80>
    ServerName example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

The configured directory must exist, and Apache must be able to create or write the destination files. Check ownership, permissions, filesystem availability, and any security policy that restricts access. A request may appear in a global log or another virtual-host log if the hostname, port, or active virtual-host selection is not what you expect.

Apache LogLevel severity

LogLevel sets the minimum severity recorded in the error log. A common normal setting is warn. More verbose levels include messages below that threshold; less verbose settings record only more serious events.

LevelRelative severityTypical use or meaning
debugMost verboseDetailed diagnostic information; use briefly and selectively
infoVery verboseInformational events useful during focused troubleshooting
noticeModerately lowSignificant normal or unusual events
warnCommon thresholdWarnings and more serious messages; common default in this setup
errorSeriousFailures that affect an operation or request
critVery seriousCritical conditions requiring prompt attention
alertExtremely seriousConditions requiring immediate action
emergMost seriousEmergency conditions indicating that the system may be unusable

Changing from warn to info or debug can reveal useful context, but it can also create substantial output. Increase verbosity only for a focused investigation, then restore the normal level to reduce noise and disk consumption. Severe levels describe progressively more serious conditions.

Changing logging configuration safely

  1. Edit the relevant main Apache configuration file or the virtual-host file. The exact file depends on the distribution and enabled site.
  2. Change only the required ErrorLog, CustomLog, LogFormat, or LogLevel directive.
  3. Validate the complete configuration before reloading:
sudo apache2ctl configtest

Proceed only when the result indicates a successful syntax check:

sudo systemctl reload apache2

A reload applies a valid configuration while normally allowing existing connections to finish. Do not reload blindly after an edit. A syntax error, missing module, invalid path, or unwritable log destination can prevent Apache from starting or cause logging to fail.

Practical investigations

Find a missing page

Search for the requested path and the 404 status:

sudo grep 'list.html' /var/log/apache2/access.log
sudo grep ' 404 ' /var/log/apache2/access.log

Confirm the exact URL and timestamp. Then check the document root, aliases, rewrite rules, and matching error-log entries. A 404 may be a genuinely missing file, an incorrect URL, or a mapping problem.

Investigate an internal server error

First locate the request with status 500 in access.log. Use its timestamp and URL to find the corresponding message in error.log:

sudo grep ' 500 ' /var/log/apache2/access.log
sudo tail -n 100 /var/log/apache2/error.log

The access record confirms that the client received a 500 response, but it is not usually the root cause. The error log may identify a configuration mistake, script failure, permission problem, module issue, or upstream failure.

Investigate a startup failure

If Apache does not start after a configuration change, there may be no useful new access entry because the server failed before handling requests. Run:

sudo apache2ctl configtest

Read the latest error messages and the referenced configuration file or line. Correct the issue, run the syntax check again, and reload or start Apache only after validation succeeds.

Follow both logs during a test

Open two terminals and follow the relevant files while reproducing the problem. Match entries using time, URL, virtual host, and client address. A browser request can generate multiple access entries for the page and its assets, so identify the specific failing resource rather than assuming the main page is responsible.

When requests appear in the wrong log

Expected traffic may be written to a global file or another virtual-host file when:

  • The request hostname or port selects a different VirtualHost.
  • The intended site configuration is not enabled or was not reloaded.
  • The CustomLog directive points to a different destination.
  • The log directory or file cannot be created or written.
  • A proxy or forwarding layer sends the request to a different Apache instance.

Confirm the hostname, port, active virtual-host configuration, log directives, directory permissions, and filesystem availability. Error-log warnings can provide additional clues about virtual-host selection or configuration problems.

Log rotation and disk usage

Logs grow continuously on active servers. Log rotation is the scheduled replacement, retention, archiving, or compression of growing log files. Verify that rotation is configured, that old files are retained for an appropriate period, and that compressed archives do not consume the entire filesystem.

Excessive traffic can enlarge access.log, while info or debug can enlarge error.log quickly. Restore a normal diagnostic level after troubleshooting, monitor free disk space, and investigate abnormal request patterns rather than simply deleting evidence.

Quick reference

  • Default Debian/Ubuntu paths: /var/log/apache2/access.log and /var/log/apache2/error.log.
  • CustomLog selects an access-log destination and format.
  • LogFormat defines the layout of an access entry.
  • ErrorLog selects an error-log destination.
  • LogLevel controls the minimum error-message severity recorded.
  • Use sudo tail -f to watch activity and grep to filter URLs, status codes, or client addresses.
  • Run sudo apache2ctl configtest before sudo systemctl reload apache2.
  • Use per-site logs in multi-site environments and maintain log rotation to protect disk space.

For a focused reference, see Apache access and error log administration.