You Can't Query Free Text
Before you can find patterns, you need data you can actually analyze. If your post-mortems are unstructured Google Docs full of narrative paragraphs, you cannot perform meta-analysis at scale. You cannot write a query against "the third paragraph of each document." You need structured, queryable fields attached to every incident record.
This is the unglamorous prerequisite that most organizations skip — and then wonder why their incident reviews feel like reading tea leaves.
The "Must-Have" Metadata Tags
Every incident ticket in your system (Jira, ServiceNow, PagerDuty, Linear — whatever you use) must capture these fields as required, enumerated values, not free text:
-
Severity:
SEV1,SEV2,SEV3. Defines customer impact and response urgency. -
Service / Component: e.g.,
API-Gateway,User-DB,Frontend,Payment-Service. This is the single most important field for identifying "fragile artifacts" (covered below). -
Detection Source:
Automated Alert,Customer Support Ticket,Employee Report,External Status Page. This field lets you calculate the percentage of incidents your customers discovered before you did — a metric that should embarrass any engineering organization into action. -
Root Cause Category:
Code Bug,Configuration Change,Capacity / Scaling,Dependency / Vendor Outage,Human Error,Infrastructure Failure. Keep these high-level. If you create 40 subcategories, engineers will pick randomly and your data will be noise. -
Timestamps:
Incident Start,Detection Time,Mitigation Time,Full Resolution Time. These four timestamps let you compute MTTD (Mean Time to Detect), MTTM (Mean Time to Mitigate), and MTTR (Mean Time to Resolve) — and more importantly, track trends in each independently.
Enforcement Is the Hard Part
The technical implementation is trivial. The organizational challenge is making these fields mandatory — not optional, not "fill in when you have time." In Jira, this means required fields that block ticket closure. In ServiceNow, it means validation rules. In PagerDuty, it means post-incident review templates with required sections.
The reason enforcement matters: you will need this dataset 12 months from now, when you're trying to justify a major infrastructure investment to your CTO. If 30% of your tickets have blank "Root Cause Category" fields, your analysis is compromised and your argument falls apart.
Interviewers for senior SRE and platform engineering roles often ask: "How do you measure the reliability of your systems over time?" A weak answer names a single metric like MTTR. A strong answer describes a system: structured incident metadata, aggregated quarterly, used to identify trends in detection coverage, root cause distribution, and SLO burn rate. This demonstrates that you think about reliability as an organizational capability, not just a technical one.