Run & observe

Analytics

Two views built on the same telemetry: workspace-level cost analytics at /analytics, and per-run swarm observability that replays a swarm execution node by node.

Cost analytics

The analytics page leads with four numbers — month-to-date spend, total tokens, average latency, and active agents — followed by:

Spend over time — your daily spend charted over the selected window. Spikes are worth chasing the same day; they are usually one experiment, one loop, or one oversized context.
Cost by provider — where the money goes across AgentSwarms AI, OpenAI, Anthropic, and any bring-your-own-key providers you've connected.
Cost by agent — almost always the chart with the surprise in it: one agent on one expensive model tends to dominate.

Spend caps and alerts live in Budgets; per-run detail lives in traces.

These are estimates, and they can be undercounts

Cost is computed per call from token counts and a stored price for that model — not read back from your provider's invoice, so it will not tie out exactly against a bill that applies its own rounding, discounts and minimums. Use these charts to find the expensive agent; use the invoice to settle the amount.

The sharper caveat: a model the price table does not know is recorded at zero, and zero is indistinguishable from cheap once it reaches a chart. Those calls are marked pricing_missing on the trace, and calls whose token counts were estimated rather than reported by the provider are marked tokens_estimated — so a total that looks too low can be checked rather than guessed at. See how cost is computed.

Swarm observability

Swarm runs get their own deep-inspection view at Analytics → Swarm Observability. Opening a run shows three tabs:

Canvas: The swarm graph as it was at run time, so you can see the shape of what executed — including for runs of swarms you've since edited.
Timeline: The execution order, node by node, with each step's kind and model. Clicking a step opens its detail: input, output, thinking, and tool calls.
Data flow: Every message that crossed an edge — which node produced it, which node consumed it. This is where context-window problems become visible: you can see exactly how much text was handed to each node.

The workflow that pays off: after any interesting swarm run, open its timeline and find the slowest and the most expensive step. Those two nodes are nearly always the next thing worth optimizing — a cheaper model, a tighter prompt, or a parallel branch.

Service monitoring

Observability → Monitoring answers the operator’s question rather than the analyst’s: is every piece of this deployment actually running, and what is the machine doing right now? It is superadmin-only, because it reports hostnames, container limits and which internal services exist.

Panel	What it shows
CPU	Utilisation sampled across all cores, with the core count, the container's CPU quota when one is set, and the 1/5/15-minute load averages.
Memory	Used against the total — and it says which total: a container's cgroup LIMIT when there is one, otherwise host RAM. Showing 3 GB of 64 GB while the container dies at 4 GB would be worse than showing nothing.
Disk	Usage of the filesystem the app is installed on, where the platform reports it.
App process	Resident memory, heap used against heap total, and how long this process has been up.
Services	One row per service — the app, Supabase, and every optional container — with its status, response time and the address that answered.

Note

Optional services are not incidents. A profile you never started reads “Not running” in grey, with the command that would start it — not a red “Down”. Only a required service failing, or any service answering badly, is counted in “needing attention”. A status page that cries wolf is one people stop opening.

The view refreshes every 15 seconds while open (toggleable), and each probe reports what the service itself says — the document renderer’s LibreOffice availability, for instance, appears alongside its status rather than being assumed from the fact that it answered.

The audit timeline

The timeline merges three sources at read time, which is why an action can appear here without a matching row in any single table:

Source	Contributes
`audit_events`	User and admin activities — sign-ins, publishes, grants, deletes, agent chats
`execution_traces`	Model calls, surfaced as the `model.call` action
`swarm_runs`	Swarm executions, surfaced as `swarm.run`

Non-administrators see only their own rows — the scoping is done by row-level security, not by the query — while a superadmin sees the whole workspace.

Retention

Setting	Default	Range	Notes
`audit_retention_days`	365	1 – 365	How long audit events are kept before the scheduled purge.
`trace_retention_days`	0 (keep forever)	0 – 3650	Zero means no trace purge at all. Set it deliberately — traces can hold prompt bodies.
`AUDIT_ARCHIVE_ON_PURGE`	off	env var	Archive events on purge instead of dropping them.

Traces are kept forever by default

trace_retention_days ships at 0, meaning nothing is ever purged. Combined with PERSIST_PROMPT_BODIES, that can mean full prompts and responses accumulating indefinitely — and on a busy instance execution_traces and swarm_runs are the fastest-growing tables you have. Set a window in Admin → IAM → Settings → Trace retention. The purge has always run on the scheduled maintenance pass; until that field is non-zero it simply has nothing to do. See also Budgets & cost.

Export

The audit log exports as NDJSON — one JSON object per line — which streams into most log pipelines without transformation and stays readable when the file is large.

PreviousLogs & traces Next Install & deploy