Measurement
What the platform records, where to read it, how to export it, and how ClickHouse keeps the long-term history.
On this page
TL;DR: Cost and activity are recorded in detail; value is not yet. Outcome data after a pull request opens (merge, review rounds, defects) is not captured. Which KPIs are reported is an open decision owned by the measurement-and-reporting owner.
What is recorded
| Table | Holds |
|---|---|
ai_requests |
user, model, tokens, cost, latency, status |
ai_request_attributions |
group, project, cost centre, workflow |
agent_runs |
duration, attempts, turns, tokens, cost, error class |
workflow_runs, workflow_steps |
status, cost per step |
workflow_decisions |
who decided, outcome, wait time |
governance_decisions, mcp_tool_executions, plugin_usage_events |
policy, tool and skill activity |
Governance runs in warn mode, so governance_decisions records what would
have been refused; see Governance Modes.
Reading it
- Console:
/admin/analytics,/admin/projects/{id},/admin/groups/{id},/admin/workflows/runs, and the SQL console at/admin/sql. - Exports:
GET /admin/export/{dataset}and/admin/export/transcripts, also with a personal access token.
Long-term history in ClickHouse
The clickhouse_sync job exports seven datasets every 15 minutes;
clickhouse_purge deletes Postgres rows nightly only after ClickHouse is
verified to hold them. Config is services/clickhouse/config.yaml; endpoint
and credentials are the secrets clickhouse_url, clickhouse_user,
clickhouse_password. With no URL the job is a no-op. Details:
docs/runbooks/clickhouse-export.md.
The clickhouse MCP server gives administrators read-only SQL over that
history. It ships disabled (docs/runbooks/clickhouse-mcp.md).