The on-call question — the engineering artifact that predicts AI production survival

If you are evaluating a vendor to build a production AI system for your company, there is one question that filters more cleanly than any other. It does not ask about model performance. It does not ask about cloud architecture. It does not ask about the team's MLOps credentials. The question is: who, by name, will be on call for this system at three in the morning on a Saturday?

The vendors who can answer it have operated systems. The vendors who cannot are selling something that may run for a while and will not last. This article is about why that single question is the highest-signal engineering artifact in any vendor proposal — and what an actual on-call rotation, the kind that keeps a mid-market AI system alive past its first six months, is made of.

Carry the pager

The on-call rotation is a named human being, on a published schedule, with a working phone, who has agreed to wake up if the system tells them to. That is the entire mechanism. Everything else — the alerting tooling, the escalation policy, the runbook, the incident reviews — exists to make sure that person can do their job.

This is not new and it is not specific to AI. Google's Site Reliability Engineering book frames on-call as "a critical duty that many operations and engineering teams must undertake in order to keep their services reliable and available" (Google SRE, Being On-Call). The same book is explicit that being on call requires sustainable rotations, balanced workloads, and the ability for the responder to actually fix what they are paged for. AWS's prescriptive guidance for cloud operating models names "you build it, you run it" as the destination state of a mature engineering organisation — not as a slogan, but as a structural requirement that ties production responsibility to the team that builds (AWS, Define your roadmap).

What is new in mid-market AI vendor relationships is that this question is almost never asked. The buyer evaluates the vendor on the proposal, the references, the demos, and the architecture diagrams. The proposal does not contain the words on-call. The references do not. The demos do not. The architecture diagram has a box that says "monitoring" with an arrow pointing nowhere.

A useful test: open the most recent vendor proposal you received for an AI project and search the document for the word on-call. If it is not there, you are not looking at a proposal for a production system. You are looking at a proposal for a demo that will be handed to you to operate.

Write the runbook — and update it

A runbook is the document the on-call engineer reads at three in the morning when an alert fires. It contains: what the alert means, what to check first, what the likely causes are, what the immediate mitigation is, and who to escalate to if the mitigation does not work. A runbook that does not exist is a runbook that the on-call engineer is writing live, in production, while the system is down.

Google's SRE Workbook describes playbooks (the same artifact, different name) as living documents whose primary failure mode is decay: "playbooks decay as fast as production changes" (Google SRE Workbook, On-call). The mitigation is not "write better playbooks". It is to build playbook maintenance into the operational rhythm — every alert that fires gets reviewed, every fix gets folded back into the runbook, every quarter the runbook gets audited against the system that has drifted since the last audit.

In mid-market AI engagements, the runbook is almost never delivered. The system ships, the engagement closes, the consulting firm moves on, and the buyer's internal team is handed an architecture document and a Slack channel that goes dark within a month. When the system breaks for the first time, the people who built it are not available, the runbook does not exist, and the team that has to fix it does not understand why the alert is firing. That is not an edge case. It is the default outcome of a project priced for discovery and pilot rather than for operation.

Define escalation — to a real human, not a queue

Escalation is the path the alert takes when the primary on-call engineer cannot fix it within the SLA. A real escalation policy names: the secondary, the engineering manager, the architect, the executive sponsor. Each one has a phone number. Each one has agreed to be reachable. The policy says how many minutes the system waits before escalating up the chain.

Escalation policies that fail in production share two features. The first is that they escalate into a generic team channel rather than to a named individual — which means at three in the morning, nobody is responsible. The second is that they have never been tested. The first time a real escalation runs is during the first real incident, and at least one of the named contacts has changed phone numbers since the policy was written.

The verifiable test for an escalation policy is whether the vendor has run an unannounced game day in the last quarter. If they have not, the policy is a diagram on a wiki page, not an operational artifact.

Verify the alert is real

The alerting layer is where most production AI systems quietly die. Either the alerts fire on noise (and the on-call engineer learns to ignore them, which means real alerts get ignored too), or they do not fire when they should (which means the on-call engineer finds out the system is broken from the buyer's Slack message four hours later). Both failure modes are recoverable, but only if someone is actively tuning the alerting layer against real production traffic.

Honeycomb's writing on observability is the most useful current public source on this problem in the context of AI systems specifically. The framing is that AI systems exhibit different failure modes than the classical web services that SRE doctrine was originally developed against — they degrade rather than break, they fail in ways that depend on the input distribution, and the observability layer needs to surface model behaviour, not just request latency (Honeycomb, Observability in the Age of AI). The practical implication for the on-call engineer is that the alert vocabulary for an AI system has to include model-output anomalies, not just p95 latency and error counts.

In our own engagements, the alert tuning work is roughly two weeks of post-deployment effort before the on-call engineer's life becomes sustainable. The buyer rarely budgets for it. Vendor proposals rarely scope it. It is the most common cause of a system that ships, runs for a quarter, and then becomes a Slack channel of complaints that nobody owns. The pattern is one production wins are boring describes from a different angle — the small, unsexy operational work that does not appear in any demo and that the consulting engagement model is structurally unable to price.

How the components connect

An on-call rotation is the union of four artifacts: a published schedule with named individuals, a runbook that is maintained, an escalation policy that has been tested, and an alerting layer that surfaces real signals at sustainable rates. Each one fails independently and fails silently. The cumulative reliability of the on-call rotation is the product of the four, not their sum.

The system view: an alert fires from the observability layer, the primary on-call engineer receives the page, they open the runbook, they identify the likely cause from the symptom mapping, they apply the mitigation, and if the mitigation does not work within the SLA, the escalation policy routes the page upward. When this works, an incident lasts thirty minutes. When any of the four components fails, the incident lasts until the buyer's CTO finds out at 9am the next morning, and what follows is not a triage process; it is a relationship review.

Where the mechanism breaks

The most common failure mode in mid-market AI engagements is that the vendor and the buyer never have an explicit conversation about which of the four artifacts the vendor will own after deployment, and which the buyer will own. The default assumption — that the vendor will respond to incidents because they built the system — is not contractually true unless the contract says so. The default assumption from the vendor side — that the buyer will operate the system because they paid for it — is not operationally true unless the buyer has the headcount and the skills. Most engagements end with the deployment, both sides assume the other will pick up, and the system goes unmaintained until it breaks.

The second failure mode is that the on-call engineer at the buyer's company is someone whose primary job is not the AI system. They are a backend engineer who was assigned ownership in a meeting and who has not been trained on the runbook, has not seen the alerting layer fire, and does not know what the model is supposed to do. The system breaks, the engineer pages a vendor contact who has moved on to the next engagement, and the buyer's incident response is roughly equivalent to a customer support escalation.

The third failure mode is the one that happens regardless of who owns what: the alerting layer was tuned for the system as it was deployed and has not been re-tuned since. Production traffic has drifted. The model is now producing a class of outputs the evaluation set never covered. The alerts that should have fired do not, because the threshold was set against a distribution that no longer exists.

What to verify before signing off

Before accepting a production AI system as production-ready, a buyer should be able to verify each of the following — alongside the data engineering depth checks that decide whether the data layer the model depends on will be maintained at all:

1. The on-call schedule names a primary and a secondary for the next four weeks, with phone numbers, and the named engineers have acknowledged the rotation in writing.
2. The runbook contains at least one entry per alert that can fire, written in language the secondary on-call engineer can act on at three in the morning with no additional context.
3. The escalation policy has been tested by running an unannounced game day in the last sixty days, with a written post-mortem.
4. The alerting layer has had at least one tuning pass against real production traffic, not just synthetic load.
5. The vendor's incident SLA is contractually defined for the duration of the operate phase, not as a best-effort post-deployment courtesy.
6. The handoff document explicitly names which of the four artifacts the vendor continues to own after the build phase ends, and which the buyer owns.

If any of these six items cannot be verified, the system is not ready for production. It is ready for a demo that will quietly become production over the next quarter while the on-call layer remains theoretical.

What the on-call question actually predicts

The on-call rotation is not the most technically sophisticated component of an AI system. It is the most predictive one. A vendor who cannot tell you who carries the pager at three in the morning has not built systems they had to operate. A vendor who can has — and the answer to the question is itself the strongest evaluation criterion the buyer has.

The vendor's answer to the on-call question predicts whether the system they ship will still be running in six months. Vendors paid for discovery do not have an answer; vendors paid to operate the system do.

Worth asking before the contract closes.