--- title: Observability & audit subtitle: >- See every run, measure what it cost, and prove the record hasn't been tampered with. description: >- Logs, the agent Observe page, run detail and SSE events, token/credit/timing/usage reports, reporting groups, and a tamper-evident audit log with cryptographic integrity verification. ---------------------------------------------------- You can't operate what you can't see. Rightbrain records every run, breaks down what each one used and cost, and keeps a tamper-evident audit trail of who did what. ## Logs and the Observe page Every task and agent run is captured. In the dashboard: * **Logs** shows task and agent runs across the project. * **Observe** (on an agent) is a runs table built for operating an agent in production. It includes a **Trigger** column showing what started each run — an API call, webhook, schedule, or Gmail inbox message — server-side history filters, and surfaced **failure reasons** for runs that didn't complete, including primary-model failures and integration failures. A `waiting_for_human` run is paused on an [approval](/docs/production/approvals); a `failed` run carries a reason drawn from the run's error events. ## Four levels of detail Agent telemetry nests, so you can zoom from a whole conversation down to a single tool call: 1. **Session** — the multi-turn conversation, with its aggregate credit total across every run in it. 2. **Run** — one turn: duration, tokens, credits, which tools and skills it invoked, and whether it fell back or hit an error. 3. **Events** — the ordered stream of what happened inside the run (model output, tool calls, tool results). 4. **TaskRun** — the execution of an individual Task tool the run called, with its own timing split across input processing, the LLM call, and any MCP tool time. Start at the run to triage, then drop into events or a specific TaskRun to find the cause. ## Run detail and events Open a run to see its full record: inputs, output, token counts, timing, credits used, any files it produced, and per-tool invocation records (`task_tools_invoked`, `skills_activated`, `mcp_tools_invoked`, `integration_tools_invoked`). `phase_timings` breaks the wall-clock time into phases, and `context_usage` attributes the run's input tokens by source — instructions, conversation history, task tools, MCP tools, integrations, skills — so you can see exactly what filled the context window. On tool-heavy agents that source attribution is often the surprise: a single set of integration tool declarations can account for the majority of a run's input tokens. Agent runs stream **Server-Sent Events** as they execute — text, tool calls, tool results, approval pauses, errors, and a terminal `done` (the full event reference is in [Run agents via API](/docs/api/run-agents)). Those events are retained, so you can read a completed run's events after the fact: ```bash title="Fetch an agent run's events" curl https://app.rightbrain.ai/api/v1/org/$ORG_ID/project/$PROJECT_ID/task-agent/$AGENT_ID/run/$RUN_ID/events \ -H "Authorization: Bearer $RB_API_KEY" ``` ### Debugging a failed run: a worked example The invocation records are what turn "the run looked wrong" into a root cause. Take a repo-evaluation agent whose report came back thin. Its tool records showed two MCP-bound Task tools failing with a `tool_call_id sequence mismatch`, an auto-retry hitting the same error, and the agent producing a **degraded** report from the tool calls that did succeed rather than failing outright: | | Invocations | Errors | Tokens | Duration | | ------------ | ----------- | ------ | ------- | -------- | | Healthy run | 4 | 0 | \~4,121 | \~47s | | Degraded run | 6 | 4 | \~4,845 | \~39s | More work, less output — and the failure reason sitting right there in the record. Without per-tool telemetry you'd see only a mediocre answer; with it you see exactly which tool broke and that the agent's fallback path saved the run. ## Usage reports Rightbrain aggregates run telemetry into four report types at several levels. Each is a `GET` returning aggregated figures: | Report | Task | Agent | Project | | --------------- | ------------------------------- | ------------------------------------- | ---------------------------------------------------------------- | | `token_report` | `GET …/task/{id}/token_report` | `GET …/task-agent/{id}/token_report` | — | | `credit_report` | `GET …/task/{id}/credit_report` | `GET …/task-agent/{id}/credit_report` | — | | `timing_report` | `GET …/task/{id}/timing_report` | `GET …/task-agent/{id}/timing_report` | `GET …/task-agent/timing_report`, `GET …/task_run/timing_report` | | `usage_report` | `GET …/task/{id}/usage_report` | `GET …/task-agent/{id}/usage_report` | `GET …/task-agent/usage_report`, `GET …/task_run/usage_report` | Agent usage reports include the per-model split — `primary` vs `fallback`, and `reasoning` vs `memory_compaction` — so you can see how often runs fall back and what agent memory compaction is costing you. See [Fallbacks & reliability](/docs/production/fallbacks). ```bash title="Read an agent's usage report" curl https://app.rightbrain.ai/api/v1/org/$ORG_ID/project/$PROJECT_ID/task-agent/$AGENT_ID/usage_report \ -H "Authorization: Bearer $RB_API_KEY" ``` ### Reporting groups Reporting groups let you tag runs so you can attribute usage — for example, per customer or per feature. Manage them under `…/reporting-groups`, then pass `reporting_group` as a query parameter when you run a task to file that run under the group. Reports can then be read with visibility controls per group. ## Audit log Beyond run telemetry, Rightbrain keeps an **audit log** of actions taken in a project. Audit events are read and exported through the API: | Purpose | Endpoint | | ----------------- | -------------------------- | | List audit events | `GET …/audit_event` | | Get one event | `GET …/audit_event/{id}` | | Export the log | `GET …/audit_event/export` | ### Cryptographic integrity The audit log is **tamper-evident**: events are chained so that altering or removing one breaks the chain. You can ask Rightbrain to verify the chain and prove the record is intact. ```bash title="Read the current integrity state" curl https://app.rightbrain.ai/api/v1/org/$ORG_ID/project/$PROJECT_ID/audit_event/integrity \ -H "Authorization: Bearer $RB_API_KEY" ``` ```bash title="Verify the audit chain" curl -X POST \ https://app.rightbrain.ai/api/v1/org/$ORG_ID/project/$PROJECT_ID/audit_event/integrity/verify \ -H "Authorization: Bearer $RB_API_KEY" ``` Verification is what makes the audit log defensible in a compliance review: it demonstrates the record hasn't been altered since it was written, not merely that a log exists. ## Related Consume the SSE event stream live. Read the per-model usage split. What the Trigger column reflects. Audit event and reporting group endpoints.

Failed to render this content