Linked to services
Runbooks attach to the service and incident context that responders already need.
Runbooks where the incident is.
Runbooks are not the product wedge. They are what makes the deploy and incident story useful when something breaks anyway.
Incident context
Runbook
postgres high connection count
Owner
payments platform
Recent deploy
checkout-v2, 47 files changed
Next action
pause deploy, check pool saturation
The useful runbook is the one that appears automatically.
At 3am, the team does not need a better wiki. It needs the right owner, recent deploy, relevant alert, and next step in the same place.
Incident context
Runbook
postgres high connection count
Owner
payments platform
Recent deploy
checkout-v2, 47 files changed
Next action
pause deploy, check pool saturation
Fed by deploy history
Recent deploys stay visible so responders know whether a change is part of the story.
Built for on-call
Use concise, action-oriented procedures instead of polished documents nobody reads during a page.
What belongs in a Strake runbook
Small, operational, attached to the alert.
- What is breaking and which customer path is affected.
- The owner or escalation path for the service.
- The first safe diagnostic commands or dashboard links.
- Rollback or mitigation steps that can be executed under pressure.
- Known deploy or dependency context that changes the response.
1
Alert opens
PagerDuty or manual incident context gives Strake the service and current production state.
2
Runbook appears
The linked runbook surfaces with owner, recent deploys, and the next operational step.
3
Context remains
After the incident, the deploy and runbook path becomes part of the operational record.
Start with the deploy gate.
Then attach the runbook that responders will need when the deploy breaks anyway.