Observability
See exactly where every request goes.
Observability records a trace of every request: how long it took, what it cost, which model and provider served it, and which pipeline stages ran. Each stage is its own timed span, so a trace is a true breakdown of where the time went. Recording happens after the response, so it never adds latency.
trace · spans · metrics
One trace per request, a span for every stage.
When a request is slow or costs too much, you are guessing.
A request runs through memory, retrieval, the firewall, routing and the model, and all you see is one number at the end. Was it the retrieval step, the firewall, or the model itself? Without a per-stage breakdown you cannot tell, so you cannot fix the slow part or the expensive one with any confidence.
How it works
Trace, break down, aggregate.
Turn it on and recording starts from the next call, at whatever sample rate you choose. Recording happens before a normal response is returned, and after the last chunk of a streamed one, so it never delays the first byte your user is waiting on.
- 01TraceOne trace per requestEach request produces one trace with a span for every stage that ran: memory, RAG, firewall, routing, inference and restore. Failed requests are traced too, stamped with their status.
- 02Break downOpen the waterfallOpen a trace for a span waterfall: one bar per stage, sized by how long it took, failed stages in red. It is obvious whether time went to retrieval, the firewall or the model.
- 03AggregateRoll it upThe Metrics tab rolls up your traces over a window: total requests, error rate, spend, p50 and p95 latency, and the breakdown by model and provider. Reads are always free.
Reading any of this is free, however often you look.
Why it is different
Tracing you can afford to leave on.
Some tracing slows every request, leaks sensitive content into a third-party tool, or bills you to look at your own data. This does none of those.
Zero added latency
Recording is queued after the response is returned, so the call your user waits on is never slowed by it.
Safe to record
Traces stay on EU infrastructure with the rest of the platform. Timings and status are always metadata only, captured content is pseudonymized wherever the firewall runs, and you can turn capture off per workspace.
Free to read, cheap to keep
You are metered once per recorded trace and never for reading. Sampling and a fixed retention window keep volume and storage in check.
Failures are visible
A firewall block, a refused non-EU route, an out-of-credits error or a provider error each produce a trace, so you see failures as clearly as successes.
Insight
You can leave it switched on.
Never costs you an answer
A trace is written before a normal response returns, and after the last chunk of a streamed one, so it never delays the first byte. If recording ever fails, it is logged and your request is unaffected.
Timings always, content by choice
Spans always record stage names, timings and status. What each stage was given is captured too unless you turn it off, pseudonymized wherever the firewall runs.
Metered per trace, reads free
One billable event per recorded trace, and reading traces and dashboards is always free. Sample a fraction of traffic to control volume on high-throughput tenants.
FAQ
Questions people ask about Observability.
- Does tracing slow a request down?
- No. Recording is queued after the response is returned, and after the last chunk of a streamed one, so the first byte is never delayed.
- Is prompt content stored?
- Timings and status are metadata only and always recorded. What each stage was given is captured unless you turn capture off, and it is pseudonymized wherever the Firewall runs.
- What does it cost to look at a dashboard?
- Nothing. You are metered once per recorded trace and never for reading.
- Are failed requests traced?
- Yes. A firewall block, a refused non-EU route, an out-of-credits error or a provider error each produce a trace, stamped with their status.
- Can we trace only some traffic?
- Yes. Set a sample rate to control volume, which is what high-throughput tenants usually do.
Start here
Turn on the trace.
Create a key, enable Observability, and see every request broken down stage by stage from the next call.