The problem
Behavior in production should be legible from the start.
When something goes wrong in production, the first thing you want is a single, legible picture: what the user did, what the API did, what the model did, all on one timeline. Observability that's added after the fact tends to arrive in pieces — traces without logs, metrics without traces — and the gaps are exactly where the hard problems hide.
Blueprint wires the full picture in from the start, so it's there the first time you need it.
How it works
OpenTelemetry across the stack, correlated by trace.
OpenTelemetry is instrumented in both the backend and the frontend
at scaffold time. Requests emit spans, outbound calls propagate the trace, and one
trace_id binds a whole user request — from the browser, through the
API, to the model and back.
Structured logs are tagged with the same trace ID, dashboards come ready, and model calls are tagged with latency and cost. A single failed request reads as one timeline instead of a forensic exercise across disconnected tools.
- OpenTelemetry instrumented across the backend and the frontend
- One trace ID follows a request from the browser through the API
- Structured logs tagged to the trace, with dashboards ready out of the box
- Model calls tagged with latency and cost, so spend per conversation is visible
- The same telemetry stack in local development as in production
See what production is doing.
Every Blueprint build ships with traces, logs, and metrics correlated by trace ID — the next question about production is a trace away.