Reports

The Reports hub at /reports is where a workspace’s measured work lives. It is one shell with six tabs; /reports itself is the Overview tab, so the hub route and the landing tab are the same URL. The shell — not the individual tab — owns the shared period, Export and Refresh controls.

The six tabs

Tab	Route	What it answers	Who may see it
Overview	/reports	How much work ran in this period, how much it cost, and how far it got	Every workspace member
Usage	/reports/usage	How full each provider subscription’s usage windows are, and what was spent	Members see the period figures; the saturation gauges are owner/admin
Delivery	/reports/delivery	Which agent profile is carrying which work right now	Every workspace member
Audit	/reports/audit	Who did what, to what, and when	Workspace owner or admin
Operations	/reports/operations	Whether this workspace’s dispatch, routing and breakers are healthy	Workspace owner or admin only
Scheduled reports	/reports/schedules	Which recurring reports send themselves, and whether they arrived	Members read; owner/admin manage

Operations is the one tab the hub hides. A member or viewer does not see it in the tab strip at all, and its endpoints refuse them server-side. Every other tab is always listed.

Audit is admin-gated but not hidden

Audit is restricted to the workspace owner or admin — but unlike Operations the tab stays visible to everyone. A member who opens it gets a permission error in the page instead of a hidden tab. The tab additionally needs the audit_log_workspace entitlement, which not every plan includes.

Operations is scoped to your own workspace. The cross-tenant operator console at /operator — every workspace on the instance, plus the global dispatch kill-switch — is a separate surface reachable only by an instance admin (or a deployment operator token). A workspace owner has no route to it.

The shared controls

The hub renders one period chooser, one Export and one Refresh, and shows each only on the tabs it applies to.

Control	Tabs it appears on	Effect
Period — 7d, 30d, 90d, Year	Overview, Usage, Delivery, Audit	Sets the reporting window. Default 30d
Export	Audit only	Downloads the filtered rows as JSON
Refresh	Operations only	Re-fetches the live snapshot

The period is held in memory for the session — it is not stored in the URL and does not persist across a reload. Overview and Usage have no Refresh button because they refetch whenever you change the period.

On a phone the period segment stays in the page, stretching to full width on its own line beneath the tabs; Export and Refresh are the controls that move into the top bar as icon buttons.

Overview

/reports — a windowed read of task telemetry, backed by GET /api/reports/overview. Five KPI tiles, each carrying a ▲/▼ delta against the immediately preceding window of equal length:

Tile	What it reports
Runs	Tasks that started in the window, with a per-day average and the peak day
Success rate	Completed as a percentage of started, with the failed count
Spend	Cost over the window, and the average cost per run
Avg duration	Mean wall-clock time per completed task, with the P95
LOC delivered	Lines added over the window, with the count of merged PRs

Below the tiles, the Delivery funnel shows how far the period’s work got. Each stage is a share of Planned:

Stage	Source
Planned	All tasks in the window (the 100 % baseline)
Started	Tasks that actually started
Done	Tasks that ended as completed
PR merged	Tasks whose pull request was merged

Two closeout counters sit under the funnel — Project docs updated and User docs updated — derived from the standard closeout’s changed-path signals. Both read 0 until the runner image emits changed paths for a task, so an empty pair is not evidence that no documentation was written. The closeout wiki step is deliberately not counted: a wiki note is not a repo file, so it never appears in a changed-path list.

The Model breakdown panel splits the window’s cost across models, as a share of the total. The breakdown axis is pinned to model-by-cost in this view; the endpoint itself supports four axes (agent, model, kind, project) for API callers.

Commits and deploys are not reported

The Overview reports no commit count and no deploy count. There is no per-task commit total and no task-scoped deploy linkage on the reports path, so both are absent from the data contract and from the page rather than being filled with a fabricated or proxy figure. Read merged PRs and the closeout counters instead.

Usage

/reports/usage — the per-provider subscription-saturation windows (a rolling allowance and how full it is) alongside the period’s token and cost figures, a Cost by provider split and a Cost over time trend.

The saturation gauges and the provider-cost panel are owner/admin; for a member they are simply absent rather than an error, so the tab still shows the period token/cost tiles.

For reading the gauges, the throttling band, and setting a dollar budget, see Track usage and budget.

Delivery

/reports/delivery — the delivery board: live work grouped by agent profile. One row is one agent profile; tasks that ran without a profile fall into an unassigned bucket labelled with their agent type and No profile.

This is an agent surface, not a tenant one

The delivery board groups by agent profile. It is not a grouping of people and carries no tenant meaning — the tenant is the Workspace, and the top tenant is the Organization.

The board is server-paginated (10 / 20 / 50 rows per page, default 20) with server-side sorting on every column and a debounced free-text search over profile name and agent type.

Column	What it counts
Profile	The agent profile, with its total task count
Queued	Tasks pending or queued
Running	Tasks starting or running
Attention	Tasks waiting on human input
Done / PR	Tasks that reached a terminal non-failed state
Failed	Tasks that failed or were cancelled
Last activity	When the profile last did anything
Cost	Spend attributed to the profile

There is no per-row status label — state is expressed by the five lane counts and a row tone. One status filter narrows the board:

Filter	Shows
All	Every profile
Active	Profiles with pending, queued, starting or running work
Paused	Profiles with no active work at all

Four KPI cards sit above the table: Active profiles, Throughput, Avg duration and Success. The board refreshes itself on live task events, so it tracks running work without a manual reload. It is a read-only aggregate — a per-task drill-down lives on the Tasks board.

Audit

/reports/audit — the workspace audit-event log: an append-only, read-only record of privileged and security-relevant actions (member and role changes, credential and switch mutations, grants and overrides).

Six columns, each sortable:

Column	What it carries
Time	When the event was recorded
Actor	Who or what acted
Action	The action key
Target	The kind of object acted on
Workspace	The workspace the event belongs to (hidden on a phone)
Severity	Security, Override or Change

Severity is derived from the action, not stored: an action naming a block, denial, quarantine or lockout reads Security; one naming a bypass, override, ownership transfer, member suspension or removal, a forced action or a grant reads Override; everything else is a Change. The same three values are available as a filter, alongside per-window Actor, Action and Target filters and a free-text search.

A KPI strip summarises the window — danger approvals, danger rejections, danger escalations, member changes, role changes, revocations, secret accesses and scope-bound decisions.

Selecting a row opens a detail drawer with the actor type, action, target, task, project, workspace, the correlation id and the reason, plus the event payload and — for a mutation — its before/after values. The drawer is explicitly marked immutable and read-only, and can pivot to every event sharing the same correlation id.

The payload is redacted when it is written, not when it is shown

The payload field is named payload_redacted because masking happens at write time: the audit writer runs a redactor before the row is inserted, replacing values under sensitive key names (key, token, secret, password, private, credential) and masking known provider-token shapes. The read and display path performs no further redaction — it shows what was stored. The masking is a strong heuristic, not a proof: treat the payload as sensitive, and never rely on it to scrub a secret that was passed under a harmless-looking key name.

Export downloads the complete filtered set — not just the visible page — as pretty-printed JSON named audit-events.json, paging server-side until every matching row is included. The export carries the raw event rows, including the payload and fields the table does not render, so treat the file as sensitive.

Operations

/reports/operations — a read-only operability snapshot for your own workspace, restricted to the workspace owner or admin. Nothing on this tab can be changed; it has no period chooser, and its one control is Refresh, which re-fetches every panel at once.

Panel	What it shows
Dispatch metrics	Queue depth, oldest queued item, dispatched in 24 h, last scheduler tick, dispatch rate against its cap, in-flight work against its ceiling, tick P95 and tick SLA
Throughput (24 h)	Dispatches per bucket over the last day
Queue priority distribution	How the queue splits across priorities, including unprioritized
Provider quota saturation	A gauge per credential window, flagging those near exhaustion
Error-recovery rates	How much of each error class was retried automatically
Routing decision log	The most recent routing decisions — item, routing source, the decision factors and the timestamp
Circuit breakers	Breakers currently open or recovering, with their error class, trip count and state, plus a healthy count
Slowest steps	Workflow steps ranked by P95 and maximum duration
Errors per workflow	Failures against total runs per workflow

The in-flight figure and the quota gauges on this tab are your workspace’s own slice, not instance-wide totals. The slowest-steps and errors panels use a fixed 30-day window that the period chooser does not affect.

For what the breaker states mean, when a breaker trips and recovers, and how to act on the saturation bands, see the admin how-to Operate the delivery engine.

Scheduled reports

/reports/schedules — the workspace’s recurring reports. The tab lists each schedule with its cadence, its send-times and its delivery channels, plus the Sent and Failed delivery counters and, when a delivery failed, the recent failures with the reason the transport gave. A member can read the list; creating and managing a schedule is owner/admin.

To create one, see Schedule a report.

From the web terminal

Two of these figures are also readable without opening the hub:

Command	Equivalent
usage	The Usage tab’s per-provider saturation windows (owner/admin)
budget	The workspace dollar budget — cap, month spend, remaining, alerts

See the web terminal command reference.

See also

• Track usage and budget
• Schedule a report
• Operate the delivery engine
• Web terminal commands