What Are Error Logs? Levels, Fields, and Uses

A web app starts throwing 500s. The on-call analyst does not guess. They open the error log and read the line: a timestamp, a severity of ERROR, a stack trace pointing at a database connection that timed out, and the user account that triggered it. Thirty seconds, and the question shifts from "what is wrong" to "why did the database stop answering." The error log did not fix anything. It recorded the failure in enough detail that someone could act on it.

An error log is a file that records the error conditions software hits while it runs: what failed, when, how severe it was, and usually enough context to start a diagnosis. Every operating system, server, and application of any size writes one. For an engineer the error log is how you debug. For a defender it is a detection and forensics surface, because a flood of authentication failures, a stack trace from an injected payload, or a service that crashes on a crafted input all surface here first. This guide covers what an error log is, the severity levels that classify each entry, the fields inside a line, where error logs live, and how SOC and DFIR teams put them to work.

What is an error log?

An error log is a file to which a program appends a record every time it encounters an error condition, one entry per event. The unit is the error, not the request and not the session. When something goes wrong (a function throws, a connection drops, a file will not open) the program writes a line describing it and keeps running where it can. The log is an after-the-fact account of what broke, in the order it broke.

Error logs sit in a wider family of logs, and the distinctions matter when you decide where to look. An application log records what the application did internally across all severities, from routine informational events to failures; the error log is the subset that captures failures and warnings, sometimes as its own file and sometimes as the higher-severity lines inside the application log. An access log records every request to a service and how the server answered, success or not. An audit log records security-relevant changes, like a permission grant or a config edit. The error log answers a narrower question than any of them: what failed, and how badly.

Errors come in two shapes. An unhandled error is one the code never anticipated. The program hits a condition with no matching handler, and the runtime logs it, often with a full stack trace, before the operation aborts. A handled error is one a developer expected and wrote code to catch. An exception handler logs a deliberate, often cleaner message describing the failure and how the program responded. Both end up in the log, and both are useful: the unhandled ones often expose the bugs and the crashes an attacker can trigger, while the handled ones tell you the application's own view of what went wrong.

Error log severity levels

The single most useful field in an error log is the severity level. It tells you, before you read another character, how much the entry should worry you. Most application logging frameworks use the same six-level scale, ordered here from least to most severe.

This scale is the standard set of levels in Apache Log4j 2, one of the most widely used logging libraries, and frameworks across other languages mirror it closely. TRACE is the least severe and FATAL the most. Configuring a logger at a given level emits that level and everything more severe, so a logger set to WARN writes WARN, ERROR, and FATAL and drops the chattier INFO, DEBUG, and TRACE. That threshold is exactly the knob that decides how much survives in production.

Operating-system and network logging uses a different but parallel scale. The syslog protocol, standardized in RFC 5424, defines eight numeric severities from 0 to 7: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, and 7 Debug. Lower numbers are more severe, the reverse of how the application scale reads top to bottom. When you pull errors from Linux services, network gear, or firewalls, this is the scale you are filtering on, and severity <= 3 is a reasonable first cut for "things that failed."

What an error log entry contains

A single error log line carries a small set of fields that recur across nearly every system. Knowing them lets you read a line from a source you have never seen before.

• Timestamp. When the error occurred, ideally with a timezone or UTC offset so entries from different hosts line up. A common form is ISO 8601, for example 2022-04-15T14:19:10+00:00. The timestamp is what lets you correlate the error with other logs on a shared timeline.
• Severity level. The TRACE through FATAL (or syslog 0-7) classification above. This is your first triage filter.
• Message. A human-readable description of what failed: "connection refused," "null reference," "permission denied." Handled errors tend to write a clean sentence; unhandled ones often attach a stack trace showing the exact code path that blew up.
• Source. Which component, service, module, or host emitted the entry. In aggregated logs this is what tells you which of fifty services is on fire.
• User or principal. The account or identity tied to the failing operation, when the application knows it. This is the field that turns an error into a lead, because it ties a failure to a who.
• Context attributes. Whatever else the logger attaches: an error or event ID, the client IP address, a request or trace ID, a process ID, the affected resource. These are the fields you pivot on during an investigation.

Not every log carries every field, and the order and delimiters vary by source, which is why parsing should follow the configured format rather than assume a layout. But the spine (when, how bad, what, where, and ideally who) is consistent enough that a defender can read across web servers, databases, and operating systems without relearning the format each time.

Where error logs live

Error logs are scattered across exactly the places you would expect things to break, and an investigation usually pulls from several at once.

Web and application servers. Apache HTTP Server writes an error_log separate from its access log, controlled by the ErrorLog and LogLevel directives, under /var/log/httpd on RHEL-family systems and /var/log/apache2 on Debian and Ubuntu. Nginx writes error.log under /var/log/nginx. Application frameworks and runtimes write their own error or exception logs to paths the app configures.

Operating systems. On Linux, the systemd journal collects service and kernel errors and is queried with journalctl, while older or syslog-configured systems write to /var/log/syslog on Debian and Ubuntu and /var/log/messages on RHEL-family systems. Kernel-level messages, including hardware and driver faults, are read with dmesg. On Windows, the Event Log records events classified by level, including Error, Warning, and Information, across the Application and System logs, and you read them in Event Viewer or with PowerShell's Get-WinEvent.

Databases and cloud services. Database engines keep their own error logs for failed queries, connection problems, and corruption. Cloud platforms expose error and diagnostic logging as a configurable feature, often delivered to a log store you choose, and the defaults are not always on. The recurring lesson is the same one access logs teach: confirm the logging exists before the incident, because a log nobody enabled is not there when you need it.

How defenders use error logs

Error logs are an operations tool first, but they earn a permanent place in the SOC and DFIR workflow.

Detection. Errors are signal. A burst of authentication failures in an application's error log is a brute-force or credential-stuffing attempt. Repeated 500s tied to malformed input can mean an attacker is probing for an injection or a deserialization flaw, and the stack trace often names the exact vulnerable function. A service that logs FATAL and restarts in a loop may be crashing on a crafted payload, the early shape of a denial-of-service or a working exploit. None of this needs a new tool, only the log and a query.

Forensics and incident response. After a confirmed intrusion, error logs help reconstruct what the attacker touched and what their actions broke. A stack trace can reveal the exact payload that triggered it. The errors a tool throws as it runs (a script failing on a missing dependency, a permission-denied on a file it tried to read) leave a trail of the attacker's activity. Faster triage here is the direct path to a lower mean time to resolution (MTTR), the operational metric for how long it takes to close out an issue.

Threat hunting and baselining. Normal systems produce a steady, boring background rate of low-severity errors. Knowing that baseline is what makes a deviation visible: a new error class that never appeared before, a spike of ERROR on a service that was quiet, a stack trace from a code path no legitimate user reaches. The hunt is the search for the error that does not fit.

Feeding the SIEM. On scattered hosts, error logs are just text files. Collected, parsed, and normalized into a Security Information and Event Management (SIEM) platform, they become queryable at scale and correlatable with other telemetry. A single ERROR on a login service means little on its own; tied by the SIEM to a failed-login burst and an access-log anomaly from the same IP, it becomes an alert. From there a SOAR playbook can act on the high-severity entries automatically, which is how teams turn a flood of errors into a short list of things that actually need a human.

Getting useful signal out of error logs

A raw error log is mostly noise. The work is making the rare important line findable.

• Filter to relevant severity. Capturing and alerting on everything guarantees alert fatigue. Set thresholds that match the source: alert on ERROR and FATAL, keep INFO and below for context, and reserve DEBUG/TRACE for active investigations.
• Map severity to action. Decide ahead of time what each level triggers. FATAL pages on-call; ERROR opens a ticket; WARN is reviewed in batch. The level is only useful if it drives a response.
• Route alerts to the right team. An error means nothing to a team that cannot act on it. Send each alert to the owner of the failing component, with enough context in the alert to start work without opening the log.
• Standardize the format. Structured logging (consistent fields, machine-parseable formats like JSON) is what makes aggregation and correlation possible. Inconsistent free-text logs are expensive to parse and easy to miss.
• Watch trends, not just spikes. A slow climb in a particular error class over weeks can be the early signal of a failing dependency or a slow-burn attack, the kind of pattern a single alert never shows.

Frequently Asked Questions

What is an error log?

An error log is a file that records the error conditions software encounters while running, one entry per event, capturing what failed, when, how severe it was, and context such as the affected component and user. Operating systems, servers, databases, and applications all produce them. They are used by engineers to debug and by defenders to detect attacks and reconstruct incidents.

What is the difference between an error log and an application log?

An application log records what an application does internally across all severities, from routine informational events to failures. An error log is the subset focused on failures and warnings, sometimes kept as its own file and sometimes as the higher-severity lines within the application log. Put simply, the error log is the part of the application's record that captures what went wrong.

What are the error log severity levels?

Most application logging frameworks use six levels, from least to most severe: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL. Operating-system and network logging uses the syslog scale from RFC 5424 instead: eight numeric severities from 0 Emergency (most severe) to 7 Debug (least severe). Both scales let you filter a log down to the entries that actually represent failures.

What fields are in an error log entry?

The recurring fields are a timestamp (ideally with a timezone or UTC offset), a severity level, a human-readable message often with a stack trace, the source component, and frequently the user or principal tied to the failure. Logs also attach context attributes like an error ID, client IP address, or request ID that an investigator can pivot on.

Where are error logs stored?

On Linux, Apache writes an error_log under /var/log/httpd or /var/log/apache2, Nginx writes error.log under /var/log/nginx, and the systemd journal is read with journalctl while syslog systems use /var/log/syslog or /var/log/messages. On Windows, errors are recorded in the Event Log's Application and System logs, viewable in Event Viewer. Databases and cloud services keep their own error logs in locations you configure.

How do attackers show up in error logs?

Common patterns include bursts of authentication failures (brute force or credential stuffing), repeated server errors tied to malformed input (probing for injection or deserialization flaws, often with a revealing stack trace), and services that log FATAL and crash in a loop on a crafted payload. The stack trace attached to an unhandled error frequently names the exact vulnerable function an attacker is targeting.

What is the difference between a handled and an unhandled error?

A handled error is one a developer anticipated and wrote code to catch, so an exception handler logs a deliberate, usually clean message. An unhandled error is one the code never anticipated; the runtime logs it, often with a full stack trace, before the operation aborts. Unhandled errors are especially valuable to defenders because they expose bugs and crashes that attackers can trigger.

The bottom line

An error log records what failed, when, how severely, and usually who and where, one entry per error. Application frameworks classify each entry on a TRACE to FATAL scale, operating systems and network gear use the syslog 0 to 7 scale, and the fields inside a line are consistent enough to read across web servers, databases, and operating systems.

For a defender the error log is two things at once: the fastest path to understanding why a system broke, and a detection surface where brute-force attempts, injection probes, and crash-loop exploits show up before anything else fires. The discipline that makes it pay off is the same in operations and in security: filter to the severities that matter, map each level to an action, normalize the format so the logs can be correlated, and confirm the logging is on before you need it. The error nobody recorded is the one that costs you.