SWIRLS_
PlatformObservability

Trace export

Send a live copy of your project's traces to your own observability backend over OTLP.

What it is. Stream a live copy of your project's execution and agent-session traces to an OTLP endpoint you control. Your Swirls runs land in the observability tool you already use, at full fidelity, with no translation layer.

Use it when you want Swirls runs correlated with the rest of your system in the tool you already alert on, or when your team needs run data in its own store for compliance or retention reasons.

Trace export is a paid entitlement. It is configured per project.

Supported backends

BackendNotes
DatadogOTLP intake, region-selected endpoint.
HoneycombOTLP, dataset selectable.
Grafana Tempo / CloudOTLP, basic-auth or token.
New RelicOTLP endpoint.
Generic OTLPAny OTLP-compatible backend. You supply the endpoint, protocol, and headers.

What gets exported

The same spans you see in Traces: the full execution and agent-session trees, with W3C ids intact. Because the ids are preserved, exported traces correlate with your own upstream and downstream traces when your callers propagate traceparent into Swirls. Export needs no extra instrumentation. It is a copy of the spans every run already produces.

Setting it up

In Swirls Cloud, open the project and go to Settings → Trace export.

Pick your backend, then enter the endpoint and credentials. Vendor presets fill in the right header shape, so the common case is a key and a region.

Choose a content policy and sampling ratio (see below), then send a test span. The test span goes straight to your endpoint and confirms reachability and credentials right away.

Save. Live export turns on within a few minutes. The settings page shows export health once spans start flowing.

Content policy

Export defaults to full fidelity, including prompt and completion text, because the destination is your own store and the data is your own. Enabling export sends that data to the backend you named, so enablement is an explicit, audited action.

If you do not want prompt and completion bodies landing in your downstream backend, set the content policy to redacted. That strips message bodies from the exported spans while keeping structure, timings, token counts, names, cost, and status.

Sampling

A per-project sampling ratio lets you export a fraction of traces. Sampling is trace-id consistent, so a sampled trace keeps all of its spans rather than arriving with gaps.

Credentials

Credentials are encrypted at rest and never returned in plaintext. The settings page shows a credential as configured, or by its last four characters. Rotating a key is a save. The new value takes effect on the next sync with no dropped spans.

Health

The settings page reports live export health per project: spans exported, dropped, and failed, plus the last error. Use it to confirm a destination is healthy after setup and to spot a backend that has started rejecting spans.

History

Real-time export is full fidelity. A short backend outage is absorbed by a durable retry queue and recovers without loss once your endpoint is reachable again.

History from before you enabled export, or recovery beyond the retry window, is structure-only: complete trace trees, timings, token counts, model and tool names, cost, and error status, without prompt or completion bodies. Swirls does not keep your prompt text in its own store, so that history cannot be replayed at full fidelity.

Reliability

Export runs on its own path, isolated from the store that backs the Traces view. A slow or unreachable backend degrades only your export. Your runs, your run records, and the in-product Traces view are never affected. Each project's export has its own queue and retry, so one backend being down does not stall another project.

On this page