Incident Snapshot¶
Artifact — instantiates Intermittent Failure Capture
Packages state, context, logs, timestamps, and human observations into a preserved record for later analysis.
An Incident Snapshot is a single, self-contained record assembled at the moment an incident is declared, which bundles heterogeneous evidence — the relevant logs, the surrounding context, the timestamps, the human's own observations — and binds them together under one episode identifier so the pieces stay linked as one artifact. Its defining move is linkage: it does not merely capture evidence, it packages disparate evidence so every piece is attributable to one episode and none can drift apart across the tools that produced it. It assembles a point-in-time package whose value is that the parts remain one record; it is neither a rolling buffer of live state nor a durability guarantee.
Example¶
A SaaS company's checkout service occasionally returns errors for about ninety seconds and then recovers; by the time an on-call engineer looks, every dashboard is green again. They wire an incident snapshot into the on-call flow: when the error rate crosses a threshold, a bot assembles a snapshot — the checkout service's logs for that window, the deploy-and-config context (what changed recently, which pods, upstream dependency health), the timestamps, and a prompt for the on-call to jot down what they saw — and stamps every piece with a single incident ID, posting it as one linked record in the incident channel. Weeks later, comparing three snapshots by their IDs, the team sees each coincided with a specific cache node's eviction storm — a link they would have missed before, because the logs, the deploy history, and the human note used to live in three separate tools with no shared key.
How it works¶
- On incident declaration, gather the pieces: the log slice for the episode window, contextual metadata (recent changes, dependency and configuration state), timestamps, and the responder's observations.
- Mint a single episode identifier and stamp every gathered piece with it.
- Assemble the pieces into one artifact — a bundle or record — so nothing is orphaned in the tool that produced it.
- Store or post the artifact as a unit, so it can be retrieved whole and grouped against other episodes later.
Tuning parameters¶
- Bundle breadth — how many evidence types are included. Broader is richer but heavier to assemble and to review.
- Context depth — how far back the "what changed" context reaches. Deeper surfaces slow-moving causes but adds noise.
- Human-observation prompt — structured fields versus free text. Structure aids later comparison; free text captures the unexpected.
- Identifier scheme — how episodes are keyed, which determines how cleanly they group when compared later.
When it helps, and when it misleads¶
Its strength is that it makes evidence attributable and comparable: the shared identifier is exactly what lets later analysis group episodes and find the common cause, and it solves the everyday problem of evidence scattered across five tools with no common thread. The discipline mirrors forensic chain of custody[n1] — an unbroken linkage from each piece of evidence to the episode it belongs to. Its central failure mode is that a snapshot is only as good as what gets assembled: if the window or the included evidence types are wrong, you get a beautifully linked package that omits the causal signal — thin capture, well organized. The classic misuse is hoarding snapshots without ever comparing them across IDs, which is accumulation without diagnosis. The guarding discipline is to define the bundle's contents from what past episodes actually needed, and to pair the artifact with a review that genuinely groups by identifier.
How it implements the components¶
Incident Snapshot realizes the packaging-and-linkage side of the archetype — binding evidence into one attributable record, not producing the raw signals or hardening them:
event_log— includes the relevant chronological log slice for the episode window inside the bundle.contextual_trace— captures the surrounding conditions and human observations (recent changes, dependency state, what the responder saw) that explain why this instance occurred.episode_identifier— mints and stamps one identifier across every piece, binding heterogeneous evidence into a single attributable record.
It does not maintain a rolling live buffer of recent state (capture_window, state_snapshot) — that windowing is flight_recorder's; and it does not make the packaged record tamper- or failure-resistant (evidence_preservation_rule, privacy_and_safety_filter) — that hardening is black_box_log's. Incident Snapshot assembles and links a record once; Flight Recorder keeps a continuous window, and Black Box Log armors what exists.
Related¶
- Instantiates: Intermittent Failure Capture — produces the single linked record the follow-up path reviews.
- Consumes: Flight Recorder — a dumped state buffer can be one of the pieces the snapshot binds.
- Sibling mechanisms: Flight Recorder · Trigger-Based Debug Trace · Symptom Diary · Rare Event Monitor · Automatic Diagnostic Capture · Post-Episode Evidence Review · Black Box Log
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Incident Snapshot operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it packages state, context, logs, timestamps, and human observations into a preserved record for later analysis
Independent corroboration: The frozen evidence defines Incident Snapshot as 'Packages state, context, logs, timestamps, and human observations into a preserved record for later analysis', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Packaging logs, state, timestamps, and context for later diagnosis is a software-operations and debugging artifact.
Related originating lineages:
- Criminology & Forensic Studies — Chain-of-custody practice materially supplies provenance and unbroken evidence attribution.
- Engineering & Design — Flight-data and process-event recorders independently preserve transient failure state.
- Law & Governance — Chain-of-custody discipline materially strengthens later evidentiary use.
Review resolution: Both reviewers independently assign computer_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The final form materially composes methods or concepts from more than one formative domain. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry makes that composition explicit.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Chain of custody is the documented, unbroken linkage of a piece of evidence to its origin and handling, used in forensics and law so a record's attribution cannot be challenged. The episode identifier plays the same role here — it keeps heterogeneous evidence provably tied to one episode, which is what makes later cross-episode comparison trustworthy. ↩