The on-call runbook an AI feature ships without

A backend lead at a logistics company got paged at 2am. The AI feature was failing. He was on call, he had not built the feature, and there was no runbook. So he did what anyone does at 2am with no map: he guessed. Was it the model returning bad output? The data pipeline feeding it something malformed? An integration between the two? The provider having an outage on their side? Each of those looked the same from where he sat, which was a dashboard showing red and users complaining. He spent the first hour just trying to figure out which of four systems was actually broken, and he never found a clean way to turn the feature off while he did.

By morning it was resolved, more from persistence than from any plan. The feature had shipped with tests, monitoring, and a deploy pipeline. It had shipped without the one document that matters at 2am: how to tell what broke, and how to make it stop.

Every other service that company ran had a runbook. The AI feature did not, because it was new and different and nobody had written the AI version of the questions on-call would need to answer.

An AI feature fails in more places than a normal one

The reason an AI feature needs its own runbook is that it has more independent failure sources than a typical service, and they present identically. A normal service mostly fails in its own code or its own infrastructure. An AI feature can fail in at least four places that look the same from the outside. The model can return wrong or malformed output. The data feeding the model can be bad. The integration wiring the two together can break. The provider can have an outage you do not control. On-call sees “the feature is failing” and has to distinguish four causes with no guide, at the hour they are least able to.

The turn-it-off question is just as important and just as neglected. A normal service, you can often roll back or restart. An AI feature raises harder ones. Can you disable the feature without taking down everything around it? Is there a fallback for when the model is unavailable, or does the feature just fail? Can you tell the difference between the model being wrong and the model being down? If nobody worked those out before launch, on-call is working them out live, under load, at 2am, which is the most expensive classroom there is.

What good teams do

Write the AI-specific runbook before launch, not after the first incident teaches you what it should contain.
List the failure sources and how to tell them apart: model output, input data, integration, provider. Give on-call a way to check each.
Document the kill switch. Say exactly how to turn the feature off without collapsing the systems around it.
Define the fallback. Decide what happens when the model is unavailable, and make that a designed behavior, not an accident.
Include the provider’s status page and support path. When it is the provider, on-call should confirm that in a minute, not an hour.
Rehearse it. Walk someone who did not build the feature through the runbook before launch and fix what they cannot follow.

How we approach it at Density Labs

Our AI Opportunity Assessment is a fixed two-week engagement at $2,500 that scopes real production work before you build. The on-call story is one of the last things we check and one of the most telling, because it exposes everything else. We ask a simple question: when this pages someone who did not build it, at 2am, what do they read. If the answer is nothing, that gap contains all the others, because a runbook you can actually write forces you to know your failure modes, your kill switch, and your fallback first.

This is the capstone of the pattern these stories keep circling. Close to 95 percent of AI pilots stall on integration rather than the model, and the on-call runbook is where all the integration questions come due at once: the queue, the rate limits, the async results, the regions, the failures with nowhere to go. A feature that cannot be operated at 2am is not finished, however well it demos at 2pm.

Write the runbook before launch. Name the four ways it can break, document how to turn it off, and hand it to someone who has never seen the code. If they can follow it, you are ready to ship.