Boards and the dashboard

Three surfaces carry a workspace’s live work. The dashboard (/) is the cockpit: one screen that answers what is happening right now. The tasks board (/tasks) lists the work you defined. The runs board (/runs) lists every execution, agent and workflow alike.

This page is the reference for those three surfaces — their panels, columns, filters and badges. For what a task and a run actually are, and how a workflow run’s child runs nest, read Runs and tasks first; this page never re-teaches the model.

One paging contract, three boards

The tasks and runs boards share one table primitive and one server contract: {items, total, facets}. Search, filter, sort and paging are all applied server-side over the whole scope — the board never trims one already-loaded page in the browser. A count in a tab or a facet chip is therefore the count across the workspace, not across the visible rows.

The dashboard cockpit

/ — a single fit-to-viewport board. Nothing on it is a form: every panel is a read of the same run window, and every number is a link into the surface that owns it.

The head

Control	Values	Effect
Time range	1h, 24h, 7d, 30d	Refetches the run window (up to 500 runs). Default 24h
Domain filter	All, A, W, S, P	Narrows to Agent / Workflow / Script / App runs. Applied in memory, so the switch is instant
Start run	—	Opens the unified launch dialog in place

The breadcrumb under the title reads <workspace> · all runs · live. Both segment groups and the CTA are hidden on a phone.

A brand-new workspace also gets a Get started checklist over the dimmed board, walking credentials → git → project → first task.

The panels

Panel	What it answers
KPI strip	Five cards: Active now, Waiting on you, Failed <range>, Fleet utilisation, Spend <window>
Run-Stream	The window’s runs as a chart. Three views: Duration × Status, Throughput, History (the concurrency curve). Read-only — it does not filter the board
Cockpit switcher	One segmented card carrying Concurrency (peak / total slots), Fleet (online / registered runners) and Safety (danger escalations raised this session) — each segment shows its headline number while collapsed
Attention queue	The rows that need a decision or a retry (see below)
Distribution	Three views — Matrix, Funnel, Activity. The matrix crosses the four kinds (Agent · Workflow · Script · App) with four coarse columns: running, waiting, ok, error
Spend	The range’s cost split by Kind or by Agent, over the monthly-budget bar

Each KPI card is a deep link: Active now → /runs?status=running, Waiting on you → /runs?status=waiting, Failed → /runs?status=failed&range=…, Fleet utilisation → the runner settings, Spend → the budget settings.

Two cards report a narrower window than their label

Active now carries a +N / 1h chip counting runs that arrived in the last hour, and Failed carries a ↑N vs. 24h delta comparing the last 24 hours against the 24 before it. That delta is a fixed wall-clock comparison, so it is shown only while the range is exactly 24h. The Spend card follows the head’s range, folded onto the spend API’s coarser windows (Today · 7d · 30d) — the sub-day presets both read as Today.

The attention queue

The queue is the one actionable panel, and what puts a row in it is a rule, not a curation. Over the current run window and domain filter:

Tab	A run lands here when	Row actions
Open	its status is waiting	Approve · Reject
Open	its status carries the error tone (failed, error, timeout, rejected)	Restart · Log
Resolved	it ended completed or cancelled	Restart · Log

Both lists are newest-activity-first. Each row shows the kind glyph, the task title (or the run’s own result title, or kind + short id as a last resort), the project name, and the status.

Three consequences of the rule are worth knowing:

• Approve / Reject only resolve a workflow human gate. The verdict is sent against the row’s parent workflow run and its node key. A waiting run with no workflow context has nothing to decide against, so the buttons simply open the run instead.
• Restart only appears when the row has a task. A failed workflow or script run has nothing to restart from the queue and offers Log alone, rather than a control that would do nothing.
• Selecting a row opens /tasks/{id} when the run has a task, and /runs/{id} otherwise.

A run outside the selected window or domain is not in the queue — widen the range if a decision seems to be missing. For the durable decision inbox that is not window-scoped, see Work the inbox.

Live updates

The cockpit subscribes to run-lifecycle events and refetches the window on a debounce, so the KPI strip and the queue track running work without a reload. Only lifecycle events count; an agent’s output stream never triggers a refetch.

The tasks board

/tasks — one row per task, or one row per group when several tasks were fanned out together.

Status tabs

Four tabs sit above the table, each carrying a live count computed over the whole workspace scope (not the page):

Tab	Admits
Active	running, starting, pending
All	every task, no status filter
Completed	completed
Failed	failed

Columns

Nine columns; every one of them sorts server-side. The default order is newest first (by creation time).

Column	What it carries	On a phone
Task	Status glyph + title, the git branch as a sub-line, and — once the task is finished — a one-line outcome or failure reason	shown
Agent	The agent profile’s name, falling back to the raw agent type	hidden
Model	The model pinned on the task, or —	hidden
Effort	The reasoning effort pinned on the task, or —	hidden
Project	The owning project	hidden
Status	The dual-encoded status badge	shown
Started	When the task started, as a relative time (falling back to when it was created)	hidden
Duration	Wall-clock time from start to completion	shown
Cost	The dollar figure over a muted input → output token line	shown

Toolbar

One row above the table card:

Control	Behaviour
Filter	Facet chips for Agent, Model, Effort and Project, each option labelled with its count. Active facets appear as removable chips below
Search	Debounced free-text over the task title only. Server-side, so it searches every task in scope
Columns	Show or hide individual columns
Start task	Opens /tasks/new

The pager offers 10 / 20 / 50 rows per page (default 20) and reports <shown> of <total>.

Grouped rows are never split across a page

Tasks that share a group collapse into one row showing the group label, a task count and the joined child titles; its meta cells read from the first child and its cost is the sum. Paging happens at the display-unit level, so a group is never cut in half by a page boundary. Selecting a group row opens its own aggregation page rather than the peek drawer.

Selecting a single-task row opens a peek drawer over the still-mounted list; /tasks/{id} stays a working deep link with the full view.

The runs board

/runs — one row per execution. A task is the definition; a run is one execution of it, so a restarted task appears here as several runs — see Runs and tasks.

Kind tabs

Tab	Shows
All	Every top-level run — agent, workflow and the rest
Workflows	workflow runs only
Agents	Top-level agent runs only; an agent run that is a workflow’s child is excluded

Columns

Column	What it carries	On a phone
Kind	A labelled, kind-toned pill — the run’s kind, made explicit	hidden
Run	The workflow node key, else the task / workflow name; an ×N pill for a retried attempt; and a sub-line carrying the error message, the prompt or the git branch, in that order	shown
Status	The dual-encoded status badge	shown
Trigger	How the run started	hidden
Duration	Wall-clock time	shown
Cost	The dollar figure over the input → output token line	shown
When	The creation time as a compact relative string	hidden

Sorting is server-side over a fixed whitelist: creation time, start time, finish time, status, kind, trigger, duration, cost and the run’s node key. Default is newest first.

Filters

Four facets live in the table toolbar and scope the table and the chart together:

Facet	Options
Status	All, Running, Waiting, Queued, Completed, Failed, Cancelled, Skipped, Pending
Type	All, Agent, Workflow, Loop, Code, Gate, Human, End, Wait, Telegram notify, Email notify, Webhook notify
Trigger	All, Manual, Schedule, Webhook, Linear, Notion
Wait reason	All, Waiting for event, Waiting for human

Wait reason is a composite, not a fifth axis. Picking one pins the status to Waiting and the kind to the matching node kind, so it overrides whatever the Status and Type facets said.

Search is free-text over the run’s source-issue title and identifier — not over the prompt or the log.

Above the table sit the kind tabs, the chart view switch (Duration × Status / Concurrency), the range presets 1h / 24h / 7d / 30d, a custom-range picker and — after brushing a window on the chart — a Reset range chip.

The filter selection, the range preset and the active tab are mirrored into the page URL (?status=, ?kind=, ?trigger=, ?wait_reason=, ?app_id=, ?range=, ?tab=), so a filtered board is a shareable link. The two defaults (range=24h, tab=all) are omitted, and a brushed window is deliberately not encoded.

Run kinds

The Type facet lists the kinds you can filter by, but the Kind column labels more than that. A workflow run’s children also render as their node kind — db_query, db_execute, http_request, transform, llm_classify, imap_ack and connector — reusing the workflow builder’s own node names, plus script, app and notify_discord. Those appear as labels without being offered as a filter option.

Bulk actions

The runs board has a leading checkbox column (desktop only). With a selection live, a bar appears above the table:

Action	Applies to
Replay	The terminal runs in the selection — a workflow run starts a fresh run, an agent run restarts its task
Cancel	The still-active runs in the selection
Export CSV / Export JSON	The whole selection, downloaded as runs.csv / runs.json
Clear	Drops the selection

Each run is acted on independently: one failure neither aborts the rest nor loses them. Runs that could not be processed stay selected, with a count in the bar, so you can retry exactly those.

The pager offers 10 / 20 / 50 rows per page and defaults to 50. Selecting a row opens the run peek drawer; /runs/{id} stays the full deep link.

Reading a status

Status is never colour alone — every tone also carries its own glyph shape, so the badges stay readable without colour vision.

Badge	Tone (glyph)	What it means	What to do
Pending	pending (dot)	Accepted, not started yet	Wait; nothing is wrong
Queued	warning (ring)	Parked behind a concurrency cap, not by a decision	Wait, or raise the workspace / project concurrency cap
Starting	running (pulse-dot)	The container is coming up	Wait. The runs board folds this into Running
Running	running (pulse-dot)	Executing now	Follow it, intervene, or cancel
Waiting	warning (ring)	Paused on a decision or an event, not a failure	See the two pause causes below
Paused	warning (ring)	Task-level pause	See the two pause causes below
Completed	success (check)	Finished cleanly	Read the outcome; the row’s sub-line carries the summary
Failed	error (cross)	Terminated with an error	Read the failure reason on the row, then restart or edit and restart
Cancelled	neutral (dot)	Stopped by a person or by an owning run	Restart if you still want the work
Skipped	neutral (dot)	A policy skipped it — no eligible work, a skipped author, or an unmet required status. Runs only	Nothing; the skip is the intended outcome

The two pause causes

A waiting run is not broken, and the reason it stopped decides what you do. The board shows only the status; the task detail page (/tasks/{id}) adds a calm amber banner naming the cause:

Banner	Cause	Resolution
Paused — usage window full	The provider’s prepaid usage window is exhausted	Nothing to fix. The run resumes by itself when the window refreshes; View usage opens the usage report
Paused — waiting for your decision	The agent asked a question, or needs a tool or visual approval	Review request opens the pending decision; answering it resumes the run

A usage-limit pause is deliberately not treated as a failure even though the engine also records an error — so never restart one in the hope of clearing it. For the quota case see Handle a model quota wall; for the decision case, Approve or reject agent actions. If a run failed rather than paused, start at Troubleshoot a stuck or failed run.

On a phone

Both boards keep every capability, rearranged rather than removed. The shared toolbar stays one non-wrapping row: Filter, Sort and Columns collapse to icon-only buttons that open bottom sheets instead of desktop popovers, and the search box flexes to fill the rest of the row; active facets still ride their own chip row underneath. Sort exists only here — on desktop you sort from the column headers, which a phone does not render. The desktop + New button is replaced by a round floating action button in the bottom-right thumb zone, and the multi-select checkbox column is desktop-only. Rows render as cards, the wide columns drop out, and only the list scrolls — the tabs, toolbar and pager stay put while the table card shrinks and scrolls internally.

The runs board goes one step further: its desktop tab-and-range row is hidden outright, a chart toggle moves into the top bar, and the chart becomes a separate screen rather than a block stacked above the list. The dashboard sheds its wide zones below 720 px, leaving the KPI strip, a compact activity sparkline and the attention queue; the Waiting on you card drops one breakpoint earlier so the strip stays a clean 2 × 2.

From the web terminal

The same information is readable without opening a board:

Command	Equivalent
status [--all]	The tasks board’s Active tab (--all widens it to All)
task <id>	One task’s detail, with cost, duration and last activity
runs [--status=X]	The runs board, optionally narrowed by status
approvals	The decisions behind the attention queue’s Open tab

See the web terminal command reference.

See also

• Runs and tasks
• Navigation and hubs
• Work the inbox
• Approve or reject agent actions
• Troubleshoot a stuck or failed run
• Reports