# Build an SRE incident knowledge base

A fictional tabletop exercise in three files: triage the backlog with read-only observations, respect the abort limits, and keep causation open.

## Task

Using only the three source files, triage the observed backlog, propose a read-only observation plan with its time and sampling limits, and separate hypotheses from decisions that require a human incident owner. Cite each conclusion with [[filename]].

## Expected reasoning

Record the 8.6% 5xx, 1.8-second p95, and queue depth 420 as observations; stay within the 15-minute, three-view, 20-row guardrails; abort on mutation or exposed sensitive data; and treat the 09:05 deployment as a correlation hypothesis rather than a proven cause.

## Complete source packet

### Northstar API — tabletop observations — incident-observations.md

```markdown
# Northstar API — tabletop observations

Status: fictional teaching observation sheet; no live service or customer data is involved.

At 09:10 UTC, the alert window showed 8.6% HTTP 5xx responses and 1.8 seconds p95 latency for the Northstar API. The normal reference window in this exercise is 0.4% 5xx and 350 milliseconds p95. Queue depth was 420 items; the reference value is 40.

These are observations, not a root-cause finding. This packet contains no customer identifiers, raw logs, or evidence of a particular deployment causing the change.
```

### Read-only tabletop triage guardrails — read-only-triage.md

```markdown
# Read-only tabletop triage guardrails

The responder may inspect the incident dashboard, a redacted log sample, and the deployment timeline. The observation window is at most 15 minutes, with at most three views and 20 redacted log rows. Record timestamps and observed values; do not turn correlation into causation.

Do not restart a service, change configuration, invalidate a cache, roll back a release, acknowledge a customer action, or write to an incident system. Abort immediately if a view requests a mutation, exposes an unredacted identifier or secret, or cannot show whether its data is fictional and redacted.

A human incident owner decides whether to escalate, page another team, or authorize a change.
```

### Northstar API — fictional deployment timeline — deploy-timeline.md

```markdown
# Northstar API — fictional deployment timeline

A cache-configuration deployment completed at 09:05 UTC. The incident alert began at 09:10 UTC. The timeline records those two times but does not contain a causal test, rollback approval, or owner decision.

The five-minute ordering makes the deployment a hypothesis to compare against read-only observations. It does not prove that the deployment caused the 5xx responses or latency. Rollback eligibility and the responsible owner are not specified in this packet.
```

## Reference answer: observe within limits, preserve uncertainty

The exercise supports a bounded read-only backlog observation: compare the alert values with the reference window, inspect only the named redacted views, and abort on mutation, secrets, or unredacted identifiers. The 09:05 deployment is a temporal hypothesis, not a proven cause; escalation, rollback, and ownership remain human decisions.

# Northstar API — triage reference

## Observed state

The fictional alert window records 8.6% 5xx, 1.8 seconds p95 latency, and queue depth 420, compared with reference values of 0.4%, 350 milliseconds, and 40. These are observations and do not establish a root cause. [[incident-observations.md]]

## Safe observation plan

A responder may inspect the incident dashboard, one redacted log sample, and the deployment timeline for at most 15 minutes, three views, and 20 redacted rows. The responder records timestamps and values only. Any requested mutation, unredacted identifier or secret, or unclear fictional/redaction status is an abort condition. [[read-only-triage.md]]

## Hypothesis and human decisions

The cache-configuration deployment completed at 09:05 UTC, five minutes before the alert. That makes it a candidate correlation to compare, not proof of causation. The packet does not authorize a rollback, identify an owner, or decide whether to escalate; a human incident owner must make those decisions. [[deploy-timeline.md]] [[read-only-triage.md]]

## Changed source

### deploy-timeline.md

```markdown
# Northstar API — fictional deployment timeline, revision 2

A cache-configuration review was recorded at 09:05 UTC, but it made no production change. The cache-configuration deployment completed at 09:15 UTC, after the incident alert began at 09:10 UTC. The timeline still contains no causal test, rollback approval, or owner decision.

The corrected ordering removes this deployment as an explanation for the alert onset. Other causes remain unknown. Rollback eligibility and the responsible owner are not specified in this packet.
```

## Expected change

The reference's statement that the 09:05 deployment was a candidate cause becomes stale. The 09:05 event was only a review and the actual deployment followed the alert, so it cannot explain the initial onset. The read-only limits, observed values, and human decisions about escalation or rollback remain unchanged; the incident cause is still unknown.

## Review boundary

Check the observed values, 15-minute/three-view/20-row limits, abort triggers, and event timing; leave escalation, rollback, and ownership to the incident owner.

## Comparison

A single tabletop packet can be reviewed by hand. A source-linked incident wiki becomes useful when observations, hypotheses, abort rules, and later timeline corrections must remain connected without turning notes into operational authority.

## Read the localized page

https://wenlan.app/learn/build-sre-incident-knowledge-base