When a PagerDuty incident fires at 3 a.m., the on-call wants two things: the page, and a timeline they did not have to assemble by hand. The agent watches the incident from open to resolve, pulls Datadog metrics at each state change, and writes a structured timeline to a Dock row. By the time a human is at a keyboard, the post-mortem draft is already waiting for review. The agent does not publish. A reviewer does.
PagerDuty stays the system of record for the incident itself: who was paged, when it acknowledged, when it resolved, which service. Datadog stays the system of record for the metrics and logs the agent referenced. Dock is the system of record for what the agent interpreted from that data: the timeline it assembled, the contributing-cause hypothesis, the post-mortem draft, and every reviewer touch. Each Dock row carries pagerduty_incident_id and the relevant datadog_monitor_id references back to the source records. When the agent needs current state, it re-fetches from the PagerDuty and Datadog APIs. Dock does not cache the truth. It records the interpretation.
The Incidents table
| pagerduty_incident_id | service | severity | timeline_status | post_mortem_status | drafted_by_agent | reviewer | resolved_at |
|---|---|---|---|---|---|---|---|
| PD-48211 | checkout-api | SEV-2 | complete | awaiting review | sentinel-oncall-v3 | dustin@ | 2026-05-29 04:12 UTC |
| PD-48214 | search-indexer | SEV-3 | complete | approved | sentinel-oncall-v3 | echo@ | 2026-05-29 09:48 UTC |
| PD-48219 | billing-webhooks | SEV-1 | in progress | not started | sentinel-oncall-v3 | (pending) | (open) |
The agent owns the draft columns. The reviewer owns the approve column. The two columns never collapse into one.
One workflow, start to finish
PagerDuty fires PD-48211 against checkout-api. The agent picks up the webhook, opens a Dock incident row, and begins assembling the timeline: ack time, first responder, every status update, every Datadog alert that fired in the same window. When PagerDuty marks the incident resolved, the agent drafts the post-mortem against the PagerDuty template sections: summary, impact, root cause hypothesis, contributing factors, action items. It writes the draft to the row and flips post_mortem_status to awaiting review. Dustin opens the row in the morning, edits the contributing-cause section, adds two action items the agent missed, and approves. Only after approval does the post-mortem post to the incident channel and the engineering wiki. The agent did the assembly. The human did the judgment.
Why this matters
A post-mortem that an agent publishes unreviewed is a liability. A post-mortem that an agent drafts and a human approves is leverage. The dangerous-ops contract draws that line: drafting is safe, publishing is gated. Incident communication is published-once and read-by-many, so it sits behind a two-key handshake before it leaves Dock.
The audit trail matters as much as the document. Every row records which agent identity drafted it, which reviewer approved, and what they changed. When a SEV-1 review happens two quarters later, the question "who decided to call this a contributing cause" has an answer in the row, not a guess in someone's memory. The same discipline shows up across Dock for IT operations and Dock for DevOps: the agent does the assembly work, the reviewer does the judgment work, and the row holds both.
Blameless post-mortem culture, as the Google SRE book describes it, depends on a separation between contributing causes and individual blame. An agent that drafts against a fixed template enforces that structure cheaply. A reviewer who edits and approves keeps the human judgment in the loop.
Try Dock for your next PagerDuty incident. Wire the webhook, point the agent at a Dock table, and watch the first timeline draft itself.
FAQ
Does the agent close PagerDuty incidents? No. PagerDuty stays the source of truth for incident state. The agent reads, drafts, and writes to Dock. Closing the incident is a human action in PagerDuty.
What happens if the agent gets the contributing cause wrong?
The draft sits in awaiting review. The reviewer edits the row, the change is logged against agent identity, and the corrected version is what gets approved and published.
Can the agent publish the post-mortem automatically for low-severity incidents? The contract is configurable per severity, but the default for any published artifact is human approval. Auto-publish is a policy choice the team writes down, not a default the agent assumes. See agent audit and compliance for the policy surface.
How does the agent know which Datadog metrics to include? The PagerDuty incident references the affected service. The agent queries Datadog for monitors and dashboards tagged with that service over the incident window, and links the relevant ones in the timeline. Fresh API reads only, no cached metrics.
