Skip to content
LOG-125 Logs, Records & Provider Evidence

Could a system fail before writing the event?

Yes. A system can fail after activity begins but before it writes the expected log entry.

That means the absence of a completion or result event may reflect failure in the logging process rather than non-occurrence.

Avoid the dangerous assumption

The dangerous assumption is that every attempted action reaches the stage where the normal log record is created.

It may not.

An application can crash, a device can lose power, a service can stop or storage can become unavailable. A network interruption may prevent a client from delivering an event to the server.

Some systems write a log only after an operation completes. If the process fails halfway through, there may be no normal completion entry even though partial activity occurred.

Other systems buffer records in memory and write them later. A sudden shutdown can lose those buffered events. A collector or database failure can also prevent the record from being stored.

Investigators should identify when in the process the expected event is normally written. Ask whether it records request, start, completion or outcome.

Look for crash logs, service errors, restart events, power loss, storage warnings and incomplete transactions. Alternative sources may record earlier stages, such as a client request, network connection or partial database change.

Do not assume that system failure explains the gap without evidence. Establish whether a fault occurred at the relevant time and whether it could prevent logging.

Operational takeaway

A system may fail before creating or storing the expected record, so investigators should examine process stages, crash and service evidence, and alternative logs before treating the missing event as proof that nothing happened.


Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.