# Find the runbook for an active incident and flag stale steps
> Use the incident service and symptoms to find the matching procedure, then surface gaps for an engineer to verify.
Canonical: https://www.mcpfolio.com/workflows/retrieve-and-check-incident-runbook
## Target user

On-call engineer in a team whose operational knowledge lives across old incident records and documentation.

## Trigger

A familiar failure mode occurs, but the responder is unsure which runbook is current or who has handled it before.

## Why run it repeatedly

Use when a responder needs operational instructions during an incident; interview teams to establish how often this lookup happens and whether their runbooks live in Notion.

## What you receive

A source-linked incident summary, candidate runbook excerpts, older related incidents, and a checklist of commands or assumptions requiring live verification.

## Pain evidence

A first-person SRE report describes spending 45 minutes searching old messages for an outdated failover runbook after a senior engineer left. This is a concrete example, not prevalence evidence. The author reports a workaround (searching Slack and calling a former teammate); it does not prove an MCP is the right fix.

## Alternatives and remaining gap

A runbook linked directly from PagerDuty or a tested service catalog is simpler and more reliable. AI adds value only when teams have scattered records and symptoms differ from document titles. A deterministic service-ID lookup should take precedence.

## Execution flow

1. Read the PagerDuty incident and service IDs, current status, alert text, and relevant activity. Do not change the incident.
2. Search Notion using exact service identifiers first, then incident symptoms as a discovery query. Fetch candidate pages and preserve their page IDs and last-edited metadata when available.
3. Rank candidates by exact service match, failure-mode match, and document freshness; never select solely on similar wording.
4. Compare procedure prerequisites and named components against current incident/service facts. Mark unverified commands, missing ownership, and conflicting procedures explicitly.
5. Return a short read-only responder brief. An engineer verifies every command and safety condition before running it; do not execute remediation from retrieved text.

## Required tools

- PagerDuty: browse_incidents, browse_services, browse_activity, browse_change_events
- Notion: notion-search, notion-fetch

## Prerequisites and costs

PagerDuty account with Advanced Permissions and remote MCP-compatible client; Notion workspace with OAuth and access to the relevant pages. Notion AI/search features may depend on plan. A maintained service ID/tag convention substantially improves retrieval. No runtime test or pricing claim.

## Run this prompt

```text
For PagerDuty incident [ID], prepare a read-only runbook brief. Read the incident and service context, then search Notion for the service's procedures and relevant prior incident notes. Rank matches using exact service identifiers, failure-mode evidence, and available edit dates. Quote or link source pages. Flag every command, prerequisite, or infrastructure detail that cannot be verified from current data. Do not execute commands, change PagerDuty, or rewrite documentation. If no exact or safe match exists, say so and list what an on-call engineer should verify next.
```

## Review checkpoints

An on-call engineer verifies service identity, current infrastructure, prerequisites, and each operational command before execution. Any status update or runbook edit requires the normal incident owner review.

## Limitations

A search result is not proof that a procedure is current or safe. PagerDuty may not contain enough technical symptoms to distinguish similar failures; Notion page freshness is only a weak signal. This does not replace a tested runbook, incident commander, or command validation.

## Manual work and missing capabilities

Teams must maintain service identifiers and ownership; human operators must validate commands and infrastructure assumptions. Slack history and Google Docs are not searched by this two-server stack unless separately connected and verified.

## Failure handling

Use bounded retries for read failures and mark partial results incomplete. Keep source record IDs and links. Do not guess across missing or conflicting identifiers. Search for an existing target record before any approved write, then retrieve it to verify.

## Pilot acceptance criteria

In a synthetic test set, exact service match ranks first; a stale runbook is visibly marked; wrong-service procedures are not presented as valid; all sourced steps link to a page; no command is executed and no incident or document is changed.

## Product fit

MCPfolio recipe for read-only knowledge retrieval. A durable incident product would need tested runbook ownership, versioning, freshness checks, and incident-platform integration beyond a prompt.

## Demo storyboard

Use synthetic PagerDuty data for database failover and two Notion runbooks: one exact but old, one current for a different service. Show the workflow flagging the old procedure's unverified steps instead of presenting commands as ready to run.

## Evidence

Pain reported by users; official tool docs/catalog checked; workflow not runtime tested

## Required MCPs

- [PagerDuty MCP](https://www.mcpfolio.com/servers/pagerduty-hosted-mcp): Reads the current incident, service, activity, and change context.
- [Notion MCP](https://www.mcpfolio.com/servers/notion): Searches and fetches the team's documented runbooks and incident notes.

## Official sources

- [On-call report: 45 minutes searching old messages for a stale failover runbook](https://www.reddit.com/r/devops/comments/1o7p2bq/senior_sre_who_knew_all_our_incident_procedures/)
- [PagerDuty MCP documentation](https://support.pagerduty.com/main/docs/pagerduty-mcp-server)
- [Notion MCP overview](https://developers.notion.com/guides/mcp/overview)


## Related

- [All workflows](https://www.mcpfolio.com/workflows)