For the step-by-step record of a single run, use the Replay dialog instead. It is the one monitoring surface you reach through ordinary navigation — it opens from the Replay pill at the top right of the chat page and from the Receipts button on the Tasks page. See Replay.
Tasks
The Tasks page in an organization with no tasks yet. The four stage tiles, the New Task button and the Live runs list are all visible; notice that the sidebar on the left has no Tasks entry.
/tasks is titled Beetle Tasks, “Task workspace for Beetle, backed by connected objectives and proof-oriented agent runs.” Four tiles count tasks by stage: Unresolved (everything not done, failed or archived), Running (running and reviewing together), Blocked, and Done. Below them, Live runs — “Connected objectives and handoff jobs, updated from live projection state.” — lists one row per task, most recently changed first, with Syncing in the corner while the list loads. With nothing tracked yet it reads No Beetle tasks yet.
The list is filtered by where a task came from. Only tasks created on this page, and Receipt’s own automated fix-up objectives, are listed; a run you started from chat or Slack does not appear here. Open that run from its thread and use Replay instead.
Stages
Every task is in one of eight stages, derived from the objective’s live state:What a row shows, and what you can do
Each row carries the task’s title, objective id, last change time and channel, then a one-line status written for its stage, the latest summary when there is one, and the blocker text in red when blocked. To the right sit the stage badge, a task count, and the actions:- Receipts opens the same Replay dialog you see in chat, scoped to this objective.
- Thread jumps to the chat thread bound to the objective.
- Cancel appears while the stage is New, Queued, Running, Blocked or Reviewing — the stages in which the agent still holds work that can be stopped. It asks
Cancel <title>?and explains “This stops the agent as soon as it is safe to do so. Any work already committed is kept in the objective’s receipts.” (naming the number of running tasks when there are any), and confirms with Cancel task. You then seeCancellation requested. Stopping the run now.orTask canceled.The row readsCancellation in progress. The run stops as soon as it is safe to do so.and the button reads Canceling until the projection reports a terminal stage, because the runtime stops work asynchronously. - The trash icon, whose accessible name is
Delete <title>, asksDelete <title>?, “Deleting this objective is permanent and cannot be undone. Are you sure you want to continue?”, and confirms with Delete objective. The toast reads<title> deleted.Deleting archives the objective; its receipt history survives.
Creating a task
New Task opens the create panel at/tasks?create=true (?create=1 works too), headed New task with a Draft badge. On the left, Receipt evidence has an Attach context select listing recent objectives and jobs (default No additional context), and Add to evidence copies the chosen identifiers into the form. In the middle, Task intent (“Work definition and execution controls.”) holds two lane cards — Improvement check and Add/improve integration — and the fields Title, Problem, Priority from P1 to P4, Scope, Additional evidence (labelled Context and constraints on the integration lane) and Done when (“What must be true before this is considered fixed?”). On the right, Agent handoff previews the brief the agent will receive, with Discard, Save draft and Create task.
After Create task the panel reports Queued run <jobId>. The task will appear in the queue when it starts. The task first shows in Live runs as a handoff row — Waiting for handoff worker, then Creating Receipt objective — and becomes an ordinary row once Beetle has created the objective. A handoff that cannot complete reads Handoff failed or Dispatch failed; a submission the server rejects shows the message it returned, or Beetle task creation failed. when it returns none. Without an active organization the panel refuses with Sign in to an organization before creating Beetle tasks.
Computers
The Computers page with no computers provisioned: the five capacity tiles, the four panels in their empty states — Inventory fills its space with the standby beetle rather than a list of machines — and the Beetle runners row highlighted in the sidebar footer because it is the link that opened the page.
/computers shows the live state of the compute capacity that runs background objectives. It is titled Computers, described as opensandbox capacity and live execution output — the first word is the computer provider, and opensandbox is the only one the runtime supports. A line underneath counts <n> computers · <n> active jobs.
Four panels sit below the tiles. Current work lists running jobs (
No running jobs when empty). Live output lists the stdout and stderr streams being captured (No live computer output). Inventory lists the computers themselves, and with none provisioned draws the ASCII Beetle with Beetle computer standby and “Waiting for computer logs.” Active runs lists runs in progress (No active runs).
Rows in Current work, Live output and Active runs carry a small icon button whose accessible name is Open output; Inventory rows do not. It opens a dialog titled Job output, Computer output or Run output depending on the panel, with Status, Task, Trace, Job and Lease fields plus Computer (or Sequence for a live-output row), and a terminal view in which stdout lines are prefixed $ , stderr lines [err] , and the latest runtime message > . With nothing captured it reads No computer output captured.
There is no refresh button. Like Tasks, the page is rebuilt from receipt projections as they sync, and it shows Syncing computers while that is in progress.
The Beetle runners row at the bottom of the sidebar is the one link to this page. Its badge is the number of online computers — those that are not failed, discarded or stale. The row has no hover tooltip; the breakdown is its accessible name, which reads
Beetle runners: <idle> ready, <leased> working, <waiting> waiting, <creating> warming, <unhealthy> unhealthy. The row is highlighted while you are on /computers, and also whenever a computer is leased or a job is waiting.Sessions
The Sessions page before anything has been imported: the five totals, the Refresh button, and the empty state explaining that sessions arrive from Claude activity.
/sessions is titled Sessions, “Find token waste, compliance risks, replay gaps, and reusable lessons from Claude activity.” It reads Claude Code sessions you have imported with the CLI’s receipt import or receipt observe; nothing arrives on its own, and the page reads at most the 50 most recently active imports. Until something is imported it shows No imported sessions yet, “Waiting for Claude activity. Imported sessions will appear as replayable agent runs with reflections, lessons, and evidence.” What an import captures, and the --local-only flag that keeps it on your machine, are on Observing and importing Claude Code activity.
The top strip totals Sessions, Prompts, Replies, Issues and Evidence, with a Refresh button. Unlike Tasks and Computers, this page does not update itself — it loads once and waits for Refresh.
Once sessions exist, the Agent sessions list on the left (searchable with “Search sessions, tags, models”) lets you pick one, and the page offers four modes for it: Checks, Replay, Lessons and Evidence.
The five checks
Checks mode grades the selected session against a fixed set of named checks and marks each one pass, watch or action:
The thresholds are fixed: a run counts as large at 150 turns or 500 receipts, and the last three checks stay at
Metadata only, Too small and Not ready until a session has at least 20 turns and 40 receipts. No model is called to produce them.
Timeline rows in Replay show token usage compactly, as <input> in · <output> out · <cache> cache, with values of 10,000 and above abbreviated. Lessons is three read-only cards — Lesson candidate, Review markers and Skill draft — that summarise the same signals. Evidence is deliberately loaded on demand: “Raw receipts stay out of the main replay. Load a capped evidence window only when you need the underlying event bodies.”, with a Load latest 20 button. If the page cannot read session data at all it shows Session data unavailable with the reason and a Retry button.
What is not on these pages
Model spend and plan usage are elsewhere. Usage and Billing live in organization settings and need an owner or admin role; like the three pages above they have no sidebar entry in this release, so you reach them by URL. See Usage and spend and Billing and plans. Organization-wide activity is on the Org Brain dashboard, covered in Org Brain. For operators, the runtime exposesGET /healthz, which always returns 200 and reports readiness in its body, and GET /readyz, which returns 503 when Postgres does not answer. Receipt exposes no /metrics endpoint of its own; everything else an operator watches is on Health and observability.
Next step: use Receipt from Slack.