Incident Log
Capture incidents with severity, duration and root cause.
Overview
The Incident Log is a structured place to record operational incidents as they happen and learn from them afterwards. Outages, customer-impacting bugs, security events, data-quality issues, supply chain disruptions, and safety incidents all carry the same shape: when did it start, when did it end, who was affected, what was the severity, what was the root cause, and what did we change as a result. The log captures every entry consistently so you can review the year's incidents and spot patterns rather than treating each as an isolated event.
For engineering, ops, and customer-facing teams, the log is the foundation of a learning organisation. It also feeds into status pages, customer communications, insurance discussions, and compliance audits where evidence of a working incident response process is expected.
How it works
You open an incident by entering a title, start time, initial severity, and a brief description. As the incident progresses, you update the status and add timeline notes. When it is resolved, you record the end time, the root cause, and the remediation actions taken. Severity uses a simple scale (typically SEV1 to SEV4) so trends can be measured across the year.
The list view shows duration, severity, and status so you can sort by impact and find the worst events quickly. A postmortem field captures lessons learned and the owner responsible for follow-up actions.
Examples
- Production outage. Log a SEV1 with start time, customer impact, the change that triggered it, and the rollback that resolved it.
- Data-quality issue. Track a finance reporting error from detection through fix and downstream re-reporting.
- Security event. Record a phishing attempt that bypassed filters, the response actions taken, and the controls added afterwards.
- Quarterly review. Filter by severity to count SEV1 and SEV2 incidents per month and present the trend to leadership.
FAQ
What counts as an incident?
Anything that violated an internal or external commitment and required coordinated response. If you had to wake someone up or update customers, log it.
How detailed should the timeline be?
Enough that a reader six months later can understand what happened and why. Aim for the key events rather than every keystroke.
Who owns follow-up actions?
Assign a named owner per remediation item; without an owner, the action will not happen.
Can I track near misses?
Yes, log them at the lowest severity. Patterns of near misses are often a useful early warning.
Is this a substitute for a paging tool?
No. Paging and alerting belong in dedicated systems; the log is the record kept after the page fires.