You cannot run an AI system you cannot see

Traditional software fails loudly. Exceptions fire, error rates spike, a dashboard turns red, someone gets paged. An LLM system fails politely: it returns a fluent, confident answer that happens to be wrong, and every infrastructure dashboard stays green. That difference is the whole case for LLM observability in production, and it is why we treat monitoring as a shipping requirement, on the same list as authentication.

The rule we hold is simple: if we cannot see a system, we do not put it in front of users. Not because we distrust our own builds, but because the failure modes of these systems are invisible by default, and a system nobody can see is a system nobody is actually running.

Why your current monitoring will not catch it

Your APM stack watches uptime, latency and error codes. An LLM system can be healthy on all three while its quality collapses. A model provider updates a version and answers get subtly worse. A document sync job dies quietly and the assistant keeps answering from data three weeks stale. A prompt change improves the workflow it targeted and degrades two others. Users rarely file tickets about a wrong answer; they stop trusting the tool, and you find out in the quarterly adoption numbers, months after the cause.

Trace every request, end to end

The foundation is the trace. For each request: the input, what was retrieved, every model call with its prompt and response, every tool call, the final output, latency and token counts. When a user reports a bad answer, the trace turns "strange, it works for me" into a diagnosis in minutes: retrieval pulled the wrong document, or the model ignored the right one, or the input arrived garbled from upstream. Without traces, every complaint is an unreproducible mystery, and unreproducible mysteries erode a team’s will to fix anything.

Cost per request is a product metric

Token spending does not fail loudly either; it compounds. A retry loop, a prompt that grew by accretion, a heavy user nobody predicted: we have seen systems where cost per request tripled with no feature shipped. The monthly invoice tells you a month late and cannot tell you where. Track cost per request and per workflow, tie it to the value of that workflow, and alert on the rate of change. Keeping the bill survivable at ten times the volume starts with being able to see the number move.

Quality signals and drift

Quality has no error code, so you build proxies. Explicit feedback (thumbs, a report button) is sparse but honest. Implicit signals carry more: escalation rate to humans, retries and rephrasings, abandoned sessions, how often the system declines to answer. Add a weekly human pass: thirty minutes reading a sample of real conversations against a short rubric.

Then there is drift, the slow version of failure. The questions users ask in month three are not the ones you designed for in month one. Models change underneath you. Documents age. Drift shows up in these signals long before it shows up as a complaint, which is the point of collecting them. The offline half of this discipline is an eval set you run on every change; observability is the online half, watching the system on traffic you did not predict.

Alerts that reach a human

Monitoring nobody reads is decoration. The alerts that have earned their keep across our builds: cost per hour above a ceiling, refusal and error rates above a floor, latency degradation, an escalation spike, retrieval coming back empty. Behind the alerts, one ritual: a weekly half hour where an engineer and the business owner read the worst traces of the week together. That meeting surfaces more product improvements than any brainstorm we have sat through.

The observability tools, briefly

The tooling is mature, and this is not where projects fail. Langfuse is open source and self-hostable, which makes it our default for European clients with data constraints. LangSmith and Arize Phoenix are solid managed options, and the large APM vendors now ship LLM tracing of their own. The choice matters much less than the decision to wire tracing in from day one, because retrofitting it into a system built without it means rewriting the plumbing. It is also why a proof of concept without observability proves less than it appears to: whatever it demonstrated once, nobody can see whether it still holds.

When we take a system to production in a custom AI engagement, the dashboard ships with the feature, not after it. If a vendor shows you an AI system without showing you what they will look at when it misbehaves, they have already answered your diligence question.