The Incident Knowledge Base That Pays Off

Knowledge accumulated from incidents should compound. The KB structure and the cadence.

Structure

The incident knowledge base survives or dies on its structure. Same shape across every entry; cross-linked from runbooks; named owner per entry; visible freshness signal.

Symptoms, causes, remediation triplet. Each entry follows the same shape. Reviewers know where to look without reading the whole article.
Linked from runbooks. Runbooks cross-reference KB entries by ID. The KB surfaces during the next similar incident.
Named owner per entry. The maintaining team is named. Stale entries get challenged at the quarterly review.
Last-verified date. Each entry carries a freshness stamp. Old entries get re-validated or retired.

Populate

Population happens through postmortems but is curated, not automatic. Not every postmortem yields a KB-worthy entry; the editorial filter is what keeps the KB useful.

1 to 3 entries per postmortem. Targeted KB output. Lessons extracted, not the full postmortem reposted.
Editorial curation. Per-postmortem decision: does this lesson belong in the KB? Most do not.
Quarterly quality review. Pass over duplicates, stale entries, and broken cross-references. Keeps the KB sharp rather than sprawling.
Backlink to postmortem. Each entry links to its source postmortem. Future readers can fetch the full context.

Use

The KB pays back during new incidents. On-call searches first; matched patterns mean faster diagnosis. Without that habit, the KB is decoration.

KB-first lookup during incident. The on-call’s first action is a KB search. Pattern match drives faster hypothesis ranking.
Match means faster diagnosis. Each match saves real time. Compounded across hundreds of incidents per year, the savings reshape MTTR.
Search audit log. Each search lands in an audit log so the team can analyse KB coverage. Frequent zero-results queries point to gaps.
Onboarding KB tour. New engineers walk the KB as part of onboarding. Ramp time shortens visibly.