Event Log

An event log is a continuous list of entries that a program writes about itself. Each entry records when something happened and what exactly happened. A typical entry might read: “14:02:17 – User logged in” or “14:02:19 – Access denied”. The program generates these lines automatically while it runs, and appends them to the end of a file. Think of it like a car’s logbook: it doesn’t make the driving any better, but later you can look up who drove where and when. In English, such records are called “logs”, and German experts usually use this word too.

Why nobody finds the bug without a log

Software today runs on servers that no one sits in front of directly. If an online shop goes down for twelve minutes at three in the morning, no human was there to witness it. The only trace is what the programs wrote down during that time. Without a log, all that’s left is guessing, and guessing gets expensive when there are thousands of orders per hour.

The second major reason is security. Anyone who breaks into a system almost always leaves entries behind: an unusually high number of failed login attempts, access at absurd hours, suddenly huge amounts of data leaving the premises. This is exactly why attackers often try to delete logs. For this reason, logs are immediately sent to a second, well-protected machine. Such tamper-proof logs are called audit logs; banks and hospitals are legally required to keep them.

With AI systems, there’s a third reason. A language model doesn’t always respond the same way, even to the same question. If someone complains about an incorrect or offensive response, only the log of the actual request submitted can help. The European AI Act therefore explicitly mandates automatic recording for high-risk applications.

From a single entry to a searchable mass of data

An entry usually consists of four parts. First, the timestamp, often accurate to the millisecond. Second, an identifier indicating which component wrote it. Third, a level indicating the severity of the situation: INFO for normal operation, WARN for anomalies, ERROR for actual errors. Fourth, the message itself, often accompanied by an ID number for the request.

This ID number is more important than it sounds. Modern applications consist of many small services that call each other. A single order generates entries in a dozen logs on different machines. Only because the same number is recorded everywhere can the path of the order later be reconstructed.

Large systems generate enormous volumes in the process, easily several gigabytes per day. That’s why dedicated software collects all the logs, stores them centrally, and makes them searchable. Older entries are automatically deleted after days or weeks, because storage costs money. Logging too much makes searching harder, not easier – a common beginner’s mistake.

Where logs actually show up in your life

Your own computer also keeps event logs. Windows has the Event Viewer for this, a program that lists every system start, every crash, and every faulty device. When a support technician tells you to “take a look at the logs”, this is exactly what they mean. Your router also logs which devices connected to the Wi-Fi and when.

In the news, logs mainly come up after outages and data breaches. When a company states that an attack went “undetected for six months”, this finding comes from old log files. Conversely, it’s sometimes said that the extent of an incident can’t be determined because logs were missing or deleted too soon. This is regularly a point of criticism from regulators.

Logs should not be confused with metrics and tracing. Metrics are measured values such as memory usage, i.e. numbers over time. Tracing shows the path of a request through the system. The event log, on the other hand, provides the text description of individual incidents. Experts speak of the three pillars of observability, and in practice all three are needed.