Incident response generates evidence in three places at once: PagerDuty holds the page, Datadog holds the metrics, GitHub holds the deploy that probably caused it. Reconstructing the timeline is what makes post-mortems slow. Dock gives the agent a workspace to assemble the timeline as the incident unfolds, then draft the post-mortem with every claim pointed back at a source. The on-call lead approves before it becomes the record.
PagerDuty, Datadog, and GitHub stay the system of record for the raw data. Dock is the system of record for what the AGENT INTERPRETS. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.
The incident timeline table
| Timestamp | Source | Signal | Agent interpretation | Reviewer | Status |
|---|---|---|---|---|---|
| 14:02:11 UTC | PagerDuty INC-8821 | P1 page, checkout-api 5xx spike | Customer-facing; declare SEV-2 | sre-agent-v3 | approved by @rkapoor |
| 14:03:40 UTC | Datadog monitor 44910 | error rate 0.4% to 8.2% on checkout-api | Correlates with 14:01 deploy of PR #4412 | sre-agent-v3 | approved by @rkapoor |
| 14:09:55 UTC | GitHub PR #4412 | revert merged, deploy 2c1f8a | Error rate returning to baseline by 14:12 | sre-agent-v3 | pending |
Every row links back. The PagerDuty cell opens INC-8821. The Datadog cell opens the monitor at the right window. The GitHub cell opens the PR diff. The agent identity column resolves to a credential the audit log can trace, in line with how we treat agent identity through its lifecycle.
The worked workflow
A page fires. The agent reads it from the PagerDuty API, creates a Dock row, and starts a timeline doc. It queries Datadog for monitors that alerted in the same window and pulls top error traces. It queries GitHub for deploys in the last hour and reads any merged PR diff. It writes one interpretation row per signal, each carrying the source ID, payload pointer, and the agent's reading.
When the incident closes, the agent drafts the post-mortem in a Dock doc: summary, timeline, contributing factors, action items. Every timeline sentence links to the Dock row that backs it, which links to PagerDuty, Datadog, or GitHub. The on-call lead reviews, edits the framing, and approves. Approval flips the doc to read-only and writes reviewer plus timestamp to the audit trail. This matches the dangerous-ops contract we apply anywhere an agent produces a record of consequence.
Why it matters
Post-mortems lose value when nobody can tell which claims are evidence and which are guesses. The Google SRE Workbook frames blameless post-mortem culture as "more reliable systems" through systems-not-people analysis (sre.google). DORA's revised five-metric model tracks failed deployment recovery time as a primary signal of engineering health (dora.dev). Both depend on a faithful record. Dock produces that record as a byproduct of the response, with attribution baked in, the same pattern we apply across Dock for IT operations and agent audit and compliance. The agent is fast; the on-call lead is accountable. That split is what Cloud 2.0 for engineering was always going to mean.
Try it on your next incident
Connect PagerDuty, Datadog, and GitHub. Read more in Dock for DevOps.
FAQ
Q: Does the agent close incidents on its own? A: No. The agent drafts. The on-call lead approves. PagerDuty stays the source of truth for incident state; Dock records what the agent interpreted along the way.
Q: What if Datadog data changes after the post-mortem is approved? A: The Dock row carries a pointer, not a snapshot. When someone reopens the doc, the agent can re-fetch and append a note. The approved version stays immutable; new context arrives as a new row.
Q: How is this different from runbook automation? A: Runbook tools execute steps. Dock records interpretations with attribution. The agent can still call runbooks; Dock adds the reviewable record of why it called them.
Q: Who can approve a post-mortem draft? A: Whoever workspace policy names. Usually the on-call lead. The reviewer's identity is written to the audit trail next to the agent's, so accountability lands on a person.