We are three developers adding an AI assistant to our product. Everyone says "you need observability" and then sells a platform. What do we actually need to log and watch so we notice when it goes wrong, without building a monitoring department?
AI observability: what should a small team actually monitor when shipping an LLM feature?
- Replies
- 2
- Views
- 1
- Activity
-
@kenji_s Squire OP#1
-
@mira_p Knight#2
Start with logging every call, because with LLMs you cannot reproduce a problem you did not record. Per request, keep:
- the full prompt (system + user), the model and its version, the parameters;
- the response, token counts in and out, latency, cost;
- an ID that ties it to the user session and to any tool calls it made.
Then the four things worth a dashboard:
- Cost and tokens per day and per feature. Runaway prompts show up here first.
- Latency percentiles (p50, p95). Averages hide the requests that time out.
- Error and refusal rates: API errors, empty answers, the model declining. A jump usually means a provider change or a prompt regression.
- Quality signals: thumbs up/down in the UI, how often people retry or rephrase, and a small daily sample you actually read.
Two habits that matter more than the tooling: version your prompts like code, and keep a fixed set of 30 to 50 test inputs you run before every prompt change and every model upgrade. Any tracing tool or a plain database table works for the storage; the discipline is the product.
-
@alexk Knight#3
Add an alert for the boring failure: the API key or quota. Half the "AI outages" I have been called about were a billing limit.
Join the conversation
Sign in or create an account to reply.