Reading the Dashboard

Reading the Dashboard

The dashboard is a live operational view, not merely a list of chat logs. Read it from broad signal to specific evidence.

A reliable scan order

1. Connection and freshness — confirm the UI is connected and note the newest activity timestamp.
2. Overview totals — use active sessions, agents, tokens, and cost to spot changes in scale.
3. Session state — filter by project, provider, status, or source before comparing sessions.
4. Agent hierarchy — expand the session to see whether work moved to a subagent.
5. Timeline and transcript — inspect the latest concrete event before acting.

Reading status correctly

State	Usually means	Verify before acting
Active/working	Recent activity indicates ongoing work	Latest tool or transcript timestamp advances
Waiting	The agent is waiting for input, a child, or another event	Child-agent activity and last transcript entry
Completed	A terminal event or reconciliation closed the work	Expected result exists and no transcript still advances
Error/failed	A recorded operation failed	Whether the session recovered in a later event
Stale	No qualifying activity arrived inside the configured window	Provider process, hook delivery, and source health

Status is the server's best normalized interpretation. It cannot prove that a process is alive. For ambiguous cases, follow Recipe: Investigate a Stuck Session.

Filters are part of the evidence

If totals and visible rows disagree, clear filters first. Date range, project, provider, source, and status filters can make a healthy dataset look incomplete. Record active filters when sharing a screenshot so another operator can reproduce the view.

Live updates and refreshes

The browser receives server broadcasts, but a laptop sleep, proxy timeout, or server restart can interrupt the stream. If timestamps do not move:

1. refresh the browser once;
2. compare with npx ccam status or npx ccam sessions;
3. check server health;
4. then investigate hooks or remote sync.

This order avoids changing ingestion when only one browser is stale.

What a good daily check looks like

• New sessions appear under the expected project and source.
• Active cards have recent events.
• Waiting work has a plausible dependency or user prompt.
• Cost changes align with recent model activity.
• Old active sessions eventually reconcile to completed or stale.
• Alerts, if configured, are explainable from visible evidence.

Continue with Investigating Sessions and Agents.