An application log is a time-ordered record of events written by the application itself, such as a web shop, a content management system or an API service, describing what the program did, which decisions it made and what went wrong. In the monitoring and logging of servers, it complements the logs of the web server and the operating system by recording business-level events that only the application understands.
Where an access log shows that a request arrived and an error log shows that the server process failed, the application log explains why a checkout was declined, which job ran, or which external service timed out. It is the main evidence for debugging, auditing and incident analysis.
What an application log records
An application log entry typically contains a timestamp, a severity level, a message and context fields. Context fields carry identifiers such as the request ID, user ID, order number or job name, which let an engineer reconstruct one operation across many entries.
The developer decides what is logged, so the content reflects the design of the application, not a fixed server format. Good entries describe events that matter for operating the service: startup and configuration, authentication results, calls to external systems, retries, state changes and handled and unhandled exceptions.
Timestamps should use UTC with millisecond precision and an explicit time zone in ISO 8601 form. Without a consistent clock, correlating application events with access log lines and database logs on other servers becomes unreliable.
Severity levels and when to use them
Most logging libraries share a common set of severity levels, derived from the syslog tradition. Choosing the right level keeps important signals visible and controls log volume, because production systems usually record INFO and above while DEBUG stays disabled.
| Level | Meaning | Example event | Typical production setting |
|---|---|---|---|
| DEBUG | Detailed internal state for developers | Values of variables in a calculation | Off, enabled temporarily |
| INFO | Normal significant events | Order 4182 created | On |
| WARNING | Unexpected but handled situation | Payment provider slow, retrying | On |
| ERROR | Operation failed, service continues | Email to customer could not be sent | On, often alerted |
| CRITICAL or FATAL | Service cannot continue | Database unreachable at startup | On, always alerted |
Level inflation is a common problem: when routine events are logged as WARNING or ERROR, operators learn to ignore them and miss real failures. A useful rule is that an ERROR entry should require someone to act.
Application log compared with other server logs
A server produces several kinds of logs, and each answers a different diagnostic question. Knowing which one to read first shortens investigations considerably.
| Log type | Written by | Main content | Typical question |
|---|---|---|---|
| Application log | The application code | Business events, decisions, exceptions | Why did this operation behave this way |
| Access log | Web server or proxy | One line per HTTP request | Who requested what, with which status |
| Error log | Web server or runtime | Server-level errors and warnings | Why did the server fail to serve |
| System log | Operating system services | Kernel, daemons, authentication | What happened on the host |
| Audit log | Application or system | Security-relevant actions, immutable | Who changed what and when |
In PHP applications the boundary is often blurred, because uncaught PHP errors land in the PHP or web server error log, while messages written through a logging library go to a separate application file. Deciding on one destination per kind of event avoids searching three files for one incident.
Formats and storage
Application logs are written either as free-text lines or as structured records, most often one JSON object per line. Structured logs are easier to filter and aggregate, because every field has a name and a type.
| Option | Strength | Weakness | Suits |
|---|---|---|---|
| Plain text file | Readable without tools | Hard to parse reliably | Small single-server sites |
| Structured JSON lines | Machine-readable fields | Less readable by eye | Any system with central logging |
| Standard output in containers | Collected by the runtime | Needs an external collector | Container and cloud platforms |
| Syslog or journald | Unified with system logs | Limited field structure | Traditional Linux servers |
Log files grow continuously, so log rotation must compress and remove old files, typically keeping 7 to 90 days locally depending on volume and policy. Central log platforms then provide search, retention and alerting on patterns, such as a sudden rise in ERROR entries, which links logs to health checks and metrics.
Pitfalls in application logging
The most serious risk is logging sensitive data. Passwords, full card numbers, session tokens and unnecessary personal data must never appear in logs, because log files are copied, shipped and retained far more widely than databases. Data protection rules such as the GDPR also apply to personal data in logs.
- Missing correlation IDs make it impossible to follow one request across services.
- Excessive DEBUG output in production fills disks and slows the application.
- Logging inside tight loops multiplies volume without adding information.
- Swallowed exceptions without a log entry hide failures entirely.
- Inconsistent time zones break correlation with access and system logs.
Logging also has a performance cost. Synchronous writes to slow disks or remote endpoints can block request handling, so high-traffic applications use buffered or asynchronous logging and sampling for very frequent events. A bounded buffer should drop or summarize entries under pressure rather than stall the application, and every drop should itself be counted as a metric.
Explained without jargon
Imagine a ship’s logbook in which the crew writes down every important event: when the ship left port, when the weather changed, when an engine had trouble. An application log is the same kind of diary, written by a program while it works.
When something goes wrong, engineers open this diary to see what the program was doing just before the problem. A well-kept log turns guesswork into a clear story of events.
A typical use case
Customers of an online store report that some orders are charged but never confirmed. The access log shows only that the checkout requests returned status 200, and the error log is empty, so neither explains the problem.
The application log, written as JSON lines with a request ID on every entry, tells the full story. Filtering by one affected request shows the payment succeeded, followed by a WARNING that the stock service answered after 5 seconds and an ERROR that the order confirmation was rolled back because of the timeout.
Searching the central log platform reveals 37 such failures in two days, all during nightly stock synchronization. The team moves the synchronization to a quieter hour, adds a compensating refund job and creates an alert on the specific ERROR message, so a repeat would be detected within minutes instead of through customer complaints.