The short answer

AI systems fail politely: confident, well-formed, wrong, and green on every dashboard. Observability for operators means watching the four signals classic monitoring misses (silence, drift, boundaries, cost) with a setup sized to a small operation: alarms on empty responses and spend spikes, a weekly read of sampled outputs, boundary probes, and golden re-runs gating every change.

Classic monitoring answers one question: is it up? AI systems invented a failure mode that laughs at the question: up, responsive, fluent, and wrong. We learned the difference in production, on our own funnel, and the education is cheaper secondhand.

Fluent failure, the new default

Traditional software fails loudly: exceptions, 500s, timeouts, things a pager understands. Language-model systems fail fluently: the answer arrives well-formed and confident, just degraded (subtly off-policy, subtly off-tone, subtly wrong), or the stream opens and closes with nothing inside, which most health checks record as success. Our June incident was exactly this shape: every dashboard green, every visitor greeted by a mute agent. The failure taxonomy of production AI adds "observable" to the definition for precisely this reason: a system nobody can watch is a system that fails first in front of customers.

The four signals

  • –Silence. Empty and truncated responses, counted and alarmed. The cheapest signal to wire and the one that catches retired models, expired keys, and provider incidents while status codes still say 200.
  • –Drift. Sampled real outputs scored against a rubric weekly and, above all, read: tone, verbosity, boundary erosion. The instrument for change-driven drift is the golden re-run; the instrument for slow drift is a human with twenty minutes and real transcripts.
  • –Boundaries. Scheduled probes of the refusals that must hold: the pricing question, the injection attempt, the request outside scope. A boundary is only real if something tests it after every change.
  • –Cost. Token spend per task, watched for spikes. A retry loop meeting an LLM endpoint bills like a small salary, and the invoice is the alert you get last.

Up, responsive, fluent, and wrong: the failure mode the pager was never designed for.

The operator-sized setup

  1. 01Wire the silence and cost alarms first. Empty responses, truncations, and spend-per-task thresholds: an afternoon of work, most of the catastrophic-failure coverage.
  2. 02Put the deprecation calendar in the diary. Provider retirement dates are outages with published schedules; the model-lifecycle playbook covers the drill.
  3. 03Institute the weekly read. A sample of real outputs, read by the workflow owner, twenty minutes, calendared. This habit catches what no threshold does.
  4. 04Gate changes on golden re-runs. No prompt or model change ships without the set passing and the conversations read.
  5. 05Log decisions, not just requests. What the system chose and why, especially at escalations and refusals: the trail that turns incidents into fixes instead of mysteries.

What to demand in a handover

If a vendor builds your system, the observability above is a deliverable, not an aspiration: the alarms configured in your accounts, the rubric and sampling documented in the runbooks, the boundary probes scheduled, and the deprecation drill written down. It ships inside the six-part handover with everything else, and the question that verifies it is the same one from the fifteen: what broke last quarter, and how did you find out? Operators answer with a signal from this page. Everyone else finds out from a customer.