Incident Log
An incident log is a record in which a company documents every disruption to its technology: what failed, when, for how long, and what was done about it. It serves to make errors traceable and to prevent them from happening again.
When something breaks at a major internet service, it isn’t just fixed—it’s also written down. This very collection of records is called an incident log. “Incident” refers to an event or disruption, “log” means a record or logbook. Each entry states what failed, when it began, when it was resolved, and who worked on it. Often an assessment is added of how severe the incident was and which users noticed it. The name comes from shipping and aviation: for centuries, crews have kept a logbook of anything unusual.
What a company learns from its disruptions
Without a log, the same error repeats endlessly. Only once you can look up that a particular server has already been overloaded for the fourth time in three months does a pattern become visible. Individual incidents look like coincidence; many incidents side by side reveal the actual cause. The incident log is thus the foundation for improvements to the technology.
Added to this is external pressure. Banks, insurers, and operators of critical networks must report serious incidents to regulators, in the EU sometimes within hours. Anyone without a clean log cannot meet such deadlines. Contracts with business customers also often contain availability commitments, such as 99.9 percent per year. Whether this commitment was kept can only be proven with a log of downtimes.
For investors and journalists, incident logs are indirectly interesting. If outages pile up at a provider, this is a sign of technical problems or insufficient staffing. Trust is a central selling point for cloud providers—that is, companies that rent out computing power over the internet.
From alarm to finished entry
Usually, it starts with an automatic alert. Monitoring programs constantly measure whether a service responds and how fast. If a value falls outside the normal range, a ticket is created—a digital process with its own number. From this moment on, the system collects timestamps: alert triggered, taken over by a person, cause found, incident resolved.
These timestamps are used to calculate metrics. The best known is the mean time to repair. It indicates how long, on average, it takes for an outage to be resolved. If this figure decreases over months, the team is working better or the technology has become more manageable.
After major incidents, a report follows, often called a post-mortem. It describes the course of events and the cause, and lists concrete tasks so it doesn’t happen again. Good teams write these reports blamelessly: the search is for the weak point in the system, not the guilty party. It’s important to distinguish this from simple server log files. Those contain millions of technical lines automatically; an incident log contains few, human-assessed events.
Status pages, AI models, and everyday life
Almost everyone knows the public side of an incident log: the status page. When WhatsApp, an online game, or a bank account is unreachable, you’ll find a list there with times and a brief explanation. These pages are a filtered version of the internal log. Internal details such as employee names or security vulnerabilities are left out.
For AI services, the term has acquired a second meaning. There, not only outages are logged, but also model misbehavior: fabricated answers, offensive outputs, or circumvented safeguards. The EU’s legal framework for artificial intelligence explicitly requires such records for high-risk applications. Providers must document and report serious incidents.
You encounter the term in the news when, after a major outage or hacker attack, the question arises of when a company knew about the problem. The answer lies in the incident log. That is precisely why these logs are so valuable in legal disputes and to authorities.