DevOps is 8 different jobs.
Pick yours; we'll show you the workspace.

Modern incident response uses 4-6 tools at once: alerting, observability, chat, runbook wiki, postmortem doc. Investigation happens in chat; diagnosis lives in dashboards; response runs through runbooks; the artifact ends up in a doc nobody re-reads. By postmortem time, the timeline has to be reconstructed from chat scrollback.

Open one workspace per incident. Two surfaces: Timeline (table with event, actor, action, link) and Postmortem (doc). The timeline gets appended in real time, by humans, by the monitoring agent, by webhook. The postmortem doc gets drafted from the timeline data. Reconstruction is gone; the timeline IS the source of truth.

Monitoring agent watches your alerting webhook, appends timeline rows on alert fire. Response-helper agent reads the runbook library by symptom. Postmortem-drafter runs after resolution, drafts what-happened from the timeline and root-cause from resolution patterns. The on-call engineer adds judgment; the postmortem ships in 30 minutes.

Under 5 incidents per quarter, the workspace shape is overkill. If your alerting platform has no webhooks, the monitoring agent polls instead, which adds 30-60s lag. If your chat tool is the war room, keep it; Dock captures the artifact, not the channel.

Fork the incident-response-and-postmortems template. First incident: use the timeline manually, type events as they happen, draft the postmortem after. Second incident: connect your alerting webhook, run the monitoring agent. The auto-populated timeline is when the value lands.

Webhooks. Configure your alerting platform to POST to a Dock webhook URL on every alert fire. The monitoring agent appends a Timeline row with severity, source dashboard link, and current metric values. Modern alerting platforms (Datadog, Better Stack, Grafana, Opsgenie) all support webhooks natively.

Yes, via webhooks. Set a webhook on a workspace, pick the events (row.status_changed, comment.created, doc.section_appended). Your SRE agent or pager system receives the JSON payload and routes accordingly. Common pattern: incidents in Triaging status auto-page the on-call human; incidents marked Resolved auto-create a postmortem doc surface.

One Rotations table per team. Columns: engineer, week, primary or secondary, escalation contact. The rotations agent watches the table and pages the right human when an alert fires. Hand-offs happen by row update; the audit trail is immutable.

Yes. Keep the chat tool as the war room. Mirror the thread to Dock's Timeline table via webhook so the audit trail captures both. Most teams keep chat for real-time conversation and Dock for the artifact. The two complement each other; Dock doesn't replace the chat.

Yes via your CI/CD platform's webhooks or GitHub Actions. Dock surfaces the PR-ready row to your coding agent; the agent runs in your IDE or CI, opens the PR with a description that references the Timeline row. The audit trail crosses Dock and your VCS.

One workspace per audit cycle. Controls table, Evidence doc, Audit log table. Each control gets a row with status (implemented, in-progress, gap), the evidence link, the responsible owner. Auditor reviews from the workspace; the trail is auditable. We have customers running SOC 2 readiness this way.

create_row, update_row, append_doc_section for the timeline + postmortem loop. list_rows + search for routing agents. webhook events for the integration points. The 43 MCP tools cover the full surface; for DevOps specifically these 5 carry 80% of the load.

For the runbooks themselves, yes. Each runbook is a doc surface with the procedure prose. The execution audit trail (table of every run, by whom, with deviations noted) is what your wiki can't do. The runbook prose stays current because deviations get surfaced immediately.

Workspace archive-with-retention. Set the retention policy in workspace settings; archived workspaces are read-only but searchable for the policy duration. Customers running SOC 2 typically set 7-year retention on incident workspaces; we coordinate with your auditor on retention modes.

Yes. Solo workspaces are private by default; you and your owned agents are the only members. The value isn't the team aspect for solo SREs, it's the agent-as-first-class part: you'd otherwise be running monitoring + drafting + status updates through a chat thread that doesn't compound. In Dock the timeline is a real table.

Pro at $19/mo per org covers most DevOps teams (10 agents, 20 humans, 200 workspaces, 5,000 rows per workspace). Scale at $49/mo for larger teams (30 agents, 60 humans, 1,000 workspaces). Free tier (3 agents, 6 humans) works for solo SREs and small startups. No per-incident pricing, no per-agent-hour pricing.

Every row create or update stamps the agent's identity (orb + name) in createdBy / updatedBy. The Timeline table shows the full chronology with actor identity per row. Audit-trail-grade. When the postmortem agent drafts from the Timeline, it cites which agent surfaced which event.