Skip to main content
T4 epic · SRE / on-call: three evidence sources gathered in parallel, a typed timeline, then the honest part: nika:wait a settle window, re-poll the status API, and nika:assert refuses to draft a « resolved » postmortem while prod still burns. on_finally: files the journal event and the ping NO MATTER WHAT.

The job

The hour after an incident is logs, Slack archaeology and a postmortem nobody wants to start. This pipeline assembles the evidence, rebuilds the timeline as typed events, proves recovery, and leaves a draft (summary, impact, hypotheses, actions) in the incidents folder before the retro is scheduled.

The shape

The file

incident-war-room.nika.yaml

How it works

1

Evidence gathers in one wave

logs (structured capture), status_history (with retry: status pages flap during incidents) and runbook share no deps: one parallel wave, three sources.
2

Settle, recheck, PROVE

nika:wait duration: 60s gives the system a settle window, the re-poll reads .current.state, and the assert fails the run, loudly, if it isn’t operational. No optimistic postmortems.
3

on_finally always reports

Whether save success, failed or timed out, the nika:emit journal event and the on-call ping fire. Cleanup hooks are best-effort and never mask the main outcome.

Constructs you just used

Make it yours

  • Pull the incident channel export as a fourth evidence source and let the timeline cite humans, not just machines.
  • Auto-file the retro: nika:fetch method: POST to your calendar/issue API with ${{ tasks.timeline.output.events[0].at }} as the anchor.
  • Track MTTR over time: the on_finally event stream is already your dataset.

Next · CEO Monday brief

The closer: a three-branch gather, jq arithmetic, a thinking synthesis, and a run that reports its own bill.