How to write an incident log: template and example

A delivery arrives damaged. You take a quick photo, speak to someone and get on with your day. By the afternoon, the order of events is harder to recall. A short incident log helps you preserve what you observed and what happened next.

You do not need formal language to make a useful record. You need a clear sequence, concrete details and an honest distinction between what you know and what you are unsure about. This guide includes a copyable template and a fictional example.

What is an incident log?

An incident log records a particular event and its follow-up. Unlike a daily work log, which covers a whole day or shift, it keeps one situation together: a damaged delivery, an equipment problem or an unexpected interruption.

The useful questions are simple: What happened? When and where? What did you observe yourself? What action followed? What still needs checking? The same structure works on paper or in a notes app.

Write the essentials while they are fresh

Start as soon as it is practical. A short note now can hold more reliable detail than a polished account written much later. If you are writing from memory, say so. Mark an approximate time as approximate instead of choosing a precise minute you do not remember.

Separate the time of the event from the time you wrote the note. A note created at 11:20 about a delivery around 10:40 should state both. The app’s timestamp records the entry; it does not by itself establish when the event occurred.

A copyable incident log template

Copy these fields into a note and fill in only what is relevant. Use “unknown” or “not checked” rather than guessing.

• Event or reference:
• Event date and time, including whether approximate:
• Recorded on:
• Location:
• People involved or roles:
• What I directly observed:
• What someone else reported, and who:
• Actions taken and their times:
• Related photos or documents:
• Open questions and next step:

If you need to record an exact phrase, use quotation marks only when you remember or have recorded the wording accurately. Otherwise identify it as a summary. Keep observations separate from explanations you have not confirmed.

Filled example: a damaged delivery

The following example is fictional. It illustrates an everyday record, not a claim about an actual delivery.

• Event: Damaged carton, delivery A17.
• Event time: 28 September 2026, approximately 10:40.
• Recorded on: 28 September 2026, 11:20, from memory and photos.
• Location: Receiving area, rear entrance.
• Observation: One corner of the outer carton was crushed. A tear was visible along the same edge. Contents had not been checked.
• Reported information: The driver said the carton had already been damaged before arrival. This is a summary of the conversation, not an exact quote.
• Action: Photographed the outer carton around 10:45. Set it aside for inspection. Contacted the supplier at 11:05.
• Open question: Are the contents affected?
• Next step: Inspect the contents and add the supplier’s reply.

Notice what the example does not do: it does not turn an observation of damaged packaging into a conclusion about who caused it or whether the contents are broken.

Keep later updates distinct

Add a dated follow-up when you learn more: “14:15, contents checked; one item cracked. Supplier contacted again.” This is clearer than silently rewriting the original entry as though you already knew the outcome that morning.

If you discover a mistake, identify the correction and when you made it. A useful record lets you understand how your knowledge developed. It does not require pretending the first note was complete.

Use Lognote for capture and follow-up

Choose an appropriate group, write the initial note and keep related updates there. Add a recognizable reference such as #deliveryA17 so you can find the relevant entries again. The hashtag guide explains how to browse a topic across groups in the active workspace.

If you add photos, explain what they show and how they relate to the event. A photo without context can leave the same questions as a vague sentence. Keep the event time in the text whenever it differs from the entry timestamp.

For broader separation between work and personal notes, see Workspaces in Lognote. Before sharing or exporting, review the selected entries, check attachments and remove information the recipient does not need.

Common mistakes to avoid

• Mixing direct observations with assumptions about the cause.
• Writing “earlier” or “later” without a date or approximate time.
• Treating someone else’s explanation as something you witnessed.
• Adding an outcome without identifying it as a later update.
• Assuming a timestamp guarantees the accuracy or legal status of a record.

This template is for organizing personal notes. It does not replace a required workplace reporting process, and a timestamped note is not automatically tamper-proof or legally conclusive.

Start with the template, write the facts you actually know and leave a clear next step. A readable account of one event is more useful than a long document full of uncertain detail.