A dashboard is not a plan

Most teams that put an AI workflow into production also wire up monitoring: error rates, latency, queue depth, maybe a confidence-score histogram. That answers the question "is something wrong," but not "what do I do right now." The person who gets paged at 2 a.m. is rarely the person who built the workflow, and they do not have time to read the orchestration code to work out whether it is safe to let it keep running.

A runbook closes that gap. It is a short, specific document tied to each alert: what the alert means, what to check first, which action is reversible, and who to escalate to if the first two steps do not resolve it. Google's SRE book frames incident management the same way for any production system -- clear roles and a live, written response, not improvisation under pressure (https://sre.google/sre-book/managing-incidents/).

The first line of the runbook is always a kill switch

An AI workflow is unusual compared to most backend services in one respect: a bug does not just return a bad response, it can write a wrong decision into another system -- an approval, a refund, a routed case, an update to a customer record. The most important thing a runbook can tell an on-call person is how to stop new writes immediately without having to understand the whole pipeline.

That means the workflow needs an explicit, tested 'pause write-back, keep reading' mode, and the runbook needs to say exactly how to trigger it -- a flag, a config value, a feature switch -- rather than 'ask an engineer to redeploy.' Everything else in the runbook can wait a few minutes. Containing the blast radius cannot.

  • How to stop the workflow from taking further action, in one step
  • Where in-flight items land when the workflow is paused (a queue, not a void)
  • Who owns un-pausing it, and what has to be true before they do

What goes in the entry for each failure mode

A useful runbook entry is specific to one alert or one class of failure, not a general FAQ. PagerDuty's public incident response guide lays out the same shape for any on-call program: what to check, who is responsible for which decision, and what counts as resolved versus merely quiet (https://response.pagerduty.com/). For an AI workflow, that translates into a small checklist per failure mode.

For a model-provider outage: how the workflow degrades (queue, retry, or route to a person), and how to confirm it degraded correctly rather than silently dropping work. For a spike in low-confidence outputs: whether that reflects a real shift in incoming cases or a broken upstream data source, and where to look first. For a write-back rejected downstream: whether to retry, discard, or hold for manual entry, decided in advance rather than argued about mid-incident.

Runbooks expire faster than the systems they describe

A traditional runbook goes stale when the architecture changes. An AI workflow runbook goes stale on three separate clocks: the orchestration code, the prompt or model version, and the shape of the data flowing in. A prompt change can alter failure behavior without touching a single line of infrastructure, which means the review that updates the prompt is also the review that should check whether the runbook's assumptions still hold.

The practical fix is to treat the runbook as a reviewed artifact next to the workflow definition, not a wiki page written once at launch. NIST's AI Risk Management Framework makes the same point about AI systems generally: risk management has to be a continuous function of the system's lifecycle, not a one-time assessment before launch (https://www.nist.gov/itl/ai-risk-management-framework). A runbook nobody has opened since the launch review is a liability dressed up as documentation.