An error log is a file or log stream in which a server program or application records failures, warnings and diagnostic messages, each with a timestamp, a severity level and context such as the process, client or file involved. In monitoring and logs on servers, it is the first place to look when a service returns errors, refuses to start or behaves unexpectedly.
Unlike an access log, which records every request whether or not it succeeded, an error log records only events that deserve attention. Its usefulness depends on three choices: how verbose it is, where it is stored and who or what reads it, whether an administrator, a log aggregator or an alerting rule.
What an error log entry contains
A useful error log entry answers when, how severe, where and why. Most server software writes these fields in a fixed text format, while modern applications increasingly emit structured JSON that log tools can parse without regular expressions.
| Field | Example | Purpose |
|---|---|---|
| Timestamp | 2026-03-14 09:12:05 UTC | Ordering and correlation with other logs |
| Severity level | error, warn, crit | Filtering and alerting |
| Source | Process ID, module or worker | Locating the component that failed |
| Message | upstream timed out | Describing what went wrong |
| Context | Client IP, request path, file and line | Reproducing the problem |
| Request or trace ID | A unique identifier | Linking the error to access and application logs |
Recording timestamps in UTC with a consistent format avoids confusion when logs from several servers or time zones are compared.
Error logs are written either to local files, to the system journal or syslog daemon, or directly to standard error, which container platforms capture and forward. Writing to standard error is the norm for containerized services, because the platform, not the application, then handles storage, rotation and shipping to a central log system. Whatever the destination, the format should stay stable, since parsers and alert rules break when message layouts change without notice.
Severity levels and verbosity
Most servers follow the syslog severity scale defined in RFC 5424, or a close variant of it. The configured level is a threshold: the log records that level and everything more severe.
| Level | Code | Meaning | Typical response |
|---|---|---|---|
| emerg | 0 | System unusable | Immediate action |
| alert | 1 | Action required now | Page the on-call engineer |
| crit | 2 | Critical condition | Page or urgent ticket |
| error | 3 | Operation failed | Investigate soon |
| warn | 4 | Possible problem | Review trends |
| notice and info | 5 and 6 | Normal but notable events | Usually not alerted |
| debug | 7 | Detailed diagnostics | Enable only temporarily |
A production threshold of warn or error is usual. Setting debug in production can multiply log volume many times over, fill disks and expose sensitive data, so it should be enabled briefly and for a specific component.
Error logs in common server software
Each server component keeps its own error log, and troubleshooting usually means reading several of them in time order. The table lists common defaults on Linux systems; distributions and control panels may change the paths.
| Component | Common location | Level setting |
|---|---|---|
| NGINX | /var/log/nginx/error.log | error_log directive |
| Apache httpd | /var/log/apache2/error.log or /var/log/httpd/error_log | LogLevel directive |
| PHP-FPM | Pool or global error log file | log_level and error_reporting |
| MySQL and MariaDB | Server error log in the data or log directory | log_error_verbosity |
| systemd services | The journal, read with journalctl | Priority field |
Error log compared with other logs
Error logs work best together with neighboring log types, because each records a different view of the same events.
| Log type | What it records | Main question it answers |
|---|---|---|
| Error log | Failures and warnings | What went wrong and where |
| Access log | Every request with status code | Who requested what and how often it failed |
| Application log | Business events and app-level errors | What the code was doing |
| Health check | Periodic pass or fail probes | Is the service up right now |
A 502 status code in the access log, for example, often has its explanation in the web server error log, such as a refused upstream connection, and its root cause in the PHP-FPM or application log.
Managing error logs safely
- Rotate logs by size or date and compress old files, otherwise a noisy error can fill the disk and stop the server.
- Never log secrets, such as passwords, tokens or full card numbers, and limit personal data to what diagnosis requires.
- Centralize logs from several servers so that errors can be searched and correlated in one place.
- Alert on rates, not single lines, because occasional errors are normal while a sudden spike signals an incident.
- Fix recurring warnings instead of ignoring them, since a log full of known noise hides the error that matters.
The idea in brief
An error log is like a flight recorder for a server. Whenever something goes wrong, the software writes down what happened, when it happened and where.
When a website suddenly shows an error page, nobody has to guess. An administrator opens the error log, finds the entry at that exact minute and usually sees the reason in plain text, such as a missing file or a database that did not answer. The error log turns a mystery into a specific clue.
A practical scenario
Visitors to a news site report intermittent 502 Bad Gateway pages during the morning traffic peak. The access log confirms that roughly 3 percent of requests fail between 08:00 and 09:00, but it does not say why.
The administrator searches the NGINX error log for that window and finds repeated entries stating that the connection to the PHP-FPM socket was refused. The PHP-FPM error log for the same minutes contains a warning that the pool reached its maximum number of children. After the pool limit is raised to match available memory and a slow database query is optimized, the errors disappear. Correlating three error logs by timestamp located the cause in under an hour.