What Is an Event Log?

Back to Blog

What Gets Logged

A comprehensive event log captures three broad categories. First, alarm events: every time an alarm goes active, is acknowledged, and returns to normal, each stamped with the exact time. Second, operator actions: setpoint changes, valve open/close commands, pump starts and stops, mode switches from auto to manual, and alarm shelving, each attributed to the user who performed it. Third, system events: controller communication losses, device faults, logins and logouts, and configuration changes.

Every entry carries a precise timestamp, and in systems with tight time synchronization these are accurate to the millisecond. That precision is what makes a specialized form of the event log - the sequence of events (SOE) record - so useful: when a trip cascades through interlocks in a fraction of a second, high-resolution timestamps reveal the exact order in which events occurred, which the human eye could never resolve.

Why the Event Log Matters

When something goes wrong, the event log is the primary evidence. Investigators walk the log backward from the incident to find the initiating event and the sequence that followed, and to see what the operator did and when. A well-kept log turns a vague 'the compressor tripped last night' into a precise timeline: high vibration alarm at 02:14:07, operator acknowledged at 02:14:41, trip at 02:14:52.

The event log also serves shift handover and compliance. The oncoming operator reviews the log to understand what happened while they were away. Auditors use it as an audit trail to confirm who changed what and when, which matters for regulated operations. In oil and gas, event logs support incident and spill investigations, custody and operational disputes, and the routine business of understanding a facility's behavior over time. Because logs are legal and operational records, they are typically stored securely and retained for defined periods.

Making Log Entries Attributable and Trustworthy

An event log is only evidence if you can trust two things about every entry: who and when. The who requires individual user accounts. A control room where everyone works under a shared operator login produces a log that says 'operator' did everything, which is useless in an investigation and falls short of most audit expectations. Setpoint changes, commands, and acknowledgements should carry the individual account that made them, and accounts should not be shared between people or between humans and automated interfaces.

The when requires a single time discipline across every device that contributes events. If the SCADA server, the PLCs, and the RTUs each keep their own clock, events from different sources cannot be ordered against each other, and the log's central promise - reconstruction of sequence - quietly breaks. Time synchronization from a common source, a declared convention for the time zone events are stored in, and a known policy for daylight-saving transitions are prerequisites, not refinements. It also helps to record whether each timestamp was applied at the source device or at the server on arrival, since the two can differ by the whole latency of a slow link. A dedicated sequence of events recorder takes this discipline further for fast electrical events, but even an ordinary event log is only as good as its clocks.

Retention, Protection, and Getting Logs Out

Because event logs serve as legal and operational records, three storage questions need deliberate answers. Retention: how long entries are kept is set by regulatory obligations and site policy, not by whatever the default rollover happens to be - the painful discovery is always that the window of interest aged out last month. Protection: a log that operators or engineers can edit or delete is not evidence, so entries should be append-only from the user's point of view, with any deletion controlled, rare, and itself logged. Export: investigations, disputes, and audits all end with someone needing the log outside the system, filtered by time range and asset, in a format a non-operator can read.

Many operations also forward events off-box as they occur, so an independent copy exists outside the originating system. That helps both when the SCADA server itself is the thing that failed and when a security team wants control-system events inside its own tooling; audit log forwarding covers how the pattern works and what typically consumes the stream.

Reading a Log After an Upset

A disciplined reading sequence gets far more out of the same log than scrolling and hoping:

1. Fix the time window first: establish when the process was last demonstrably normal and work only forward from there.
2. Find the trip or consequence event and walk backward to the earliest abnormal entry - that candidate initiating event anchors everything else.
3. Separate the streams: alarms, operator actions, and system events read differently, and interleaving them blindly hides patterns.
4. Check for communication failures and stale data inside the window; an alarm that arrived late because a link was down will mislead the timeline.
5. Note what the operator could actually see at each moment before judging any action - the log records what happened, not what was visible.
6. Cross-check the event sequence against trend data, since the log shows discrete transitions while trends show the process moving between them.

The same discipline in miniature is what a good shift handover review does every day: scan the window since the last handover, distinguish resolved items from standing ones, and carry forward anything that is still unexplained rather than letting it fade. Crews that practice the short version daily are dramatically faster at the long version when a real investigation demands it, because the log's structure and quirks are already familiar territory.

Frequently Asked Questions