Home › Guides › Write an incident report from logs
Write an incident report from logs
Direct answer: structure it as: a summary block (file, window, entries, distinct problems, singletons), the problems ranked by severity × frequency with counts and first/last seen, one redacted sample per problem, and a timeline note tying first-seen to the deploy or change. The grouper below generates exactly this as a Markdown export.
Generate the report from a log
⚠ Raw values are visible on this screen only. Saved board data and every export stay redacted — exports never contain raw values.
Time range in file: —
This board was restored from this browser's storage — stored samples are the redacted copies by design. The raw-view toggle has no effect on restored boards.
| Severity | Problem (first sample line) | Count | First seen | Last seen |
|---|
No repeated problems — every entry in this file was seen exactly once. Check the singletons below.
Singletons — entries seen exactly once
Grouping is deterministic normalisation: timestamps, IDs, IPs and numbers are masked, then entries are matched on the masked message plus the top application frame. It groups — it does not diagnose. Check a group's samples before you act on it.
The structure, section by section
Summary first. Filename, time window, lines and entries processed, distinct problems, singleton count. Five lines that let a reader judge coverage before conclusions — and that make two reports comparable across incidents. Problems ranked. Severity × frequency order, each with count, first/last seen, exception and top frame where present, and one sample. Samples redacted. Always — the report travels further than the log does, into tickets, chats and postmortem docs; the redaction checklist applies to anything you paste in by hand.
Add the two things the log can't say
First, the timeline overlay: deploy times, config changes, traffic events, placed next to first-seen times. "Payment timeouts began 09:16; the gateway config change landed 09:14" is the sentence the whole report exists to support. Second, the gaps: what the log should contain but doesn't — the service that logged nothing after 09:12 is a finding, not an absence of one.
What to leave out
Raw dumps (link the log location instead), every sample of every group (one per problem proves the pattern), and speculation presented as finding. Mark hypotheses as hypotheses. The grouped board is evidence; the report is the argument built on it — keeping that boundary clean is what makes the next incident's report trusted. The grouping method behind the export is documented in how to group repeated errors in a log.
Frequently asked questions
What does a good incident report from logs actually contain?
A one-paragraph summary (window, volume, distinct problems, singleton count), the ranked problem list with counts and first/last seen, one redacted sample per problem, and a note of what was NOT in the log (gaps matter: missing heartbeats are evidence too). It deliberately excludes raw log dumps — the report is the analysis, the log stays in the log store.
Why include first/last seen for every problem?
Because they turn a list into a timeline. First seen aligns a problem with a deploy, a config change or a traffic event; last seen tells you whether it is ongoing or stopped (and if it stopped, what stopped it). A report without them forces every reader to redo the log work the report was meant to save.
Should the report include singletons?
As a count and, for high-severity ones, as entries. A report that only lists repeated problems teaches the dangerous lesson that rare = irrelevant, when the single FATAL at 03:12 is often the incident itself. The export from the grouper includes the singleton count automatically; promote individual severe singletons into the narrative by hand.