openclaw agent dashboard

Problem

Openclaw is an agent framework that connects AI agents to messaging apps. Its execution layer is a black box, and the bigger the system gets, the more that opacity costs you. Is it alive right now? Who's running, in what process, calling which tool? When something fails, why?

Product

A system you can observe is a system you can trust. Observability isn't adjacent to product reliability — it is product reliability.

niklaw-watchdog overview: three running agents (Tachy, Eve, Lily) with session counts, an activity timeline, open sessions, recent runs, and a live event stream. — Live at niklaw-watchdog.vercel.app — overview of three running agents (Tachy, Eve, Lily) with session counts, cost, error rate; a 24h activity timeline; and the live event stream.

Investigate view: orchestration timeline, per-session swimlane, and one turn expanded with exec output, model, provider, and tools. — Investigate — drill into one agent's orchestration timeline, per-session swimlane, and turn-by-turn execution with tools, prompts, and errors.

Trends view: cumulative cost over time across three agents totaling $61.50, error rate by agent, and per-agent session activity. — Trends — thirteen days of production data: cumulative cost across agents ($61.50 total), error rate, and per-agent session activity.

Reconstructing the tree

Openclaw never emits an execution tree — it leaves one scattered across the filesystem. Spawn metadata lives in SQLite (flows, tasks) and JSON (subagents, cron); the actual work lives in per-session JSONL transcripts. Each child points upward to its parent through a different field, and a Task tool call buried inside a transcript is the only edge binding a session to the subagent it spawns. Reconstructing "who's running, under what" means following those pointers, source by source — including the documented gap where spawnMode:"session" subagents leave a transcript but no spawn record at all.

Hierarchy from Gateway through Flow/Cron/Root-session into Session, then Task tool call to Subagent run, each node labeled with its backing file or table. — OpenClaw's execution tree, reconstructed from on-disk state: three spawn roots (flow, cron, root session) converge into a session, whose Task tool calls spawn subagents that recurse — with the spawnMode:'session' gap that hides subagents from runs.json.

The pipeline

Openclaw writes nothing for an observer; it just mutates files. So the watchdog is a daemon that watches ~/.openclaw/ on a tick, reads each source with a purpose-built collector, writes the reconstructed state into Postgres, and the dashboard renders it live. The whole thing is two workspaces — a Node collector and a Next.js app — with Supabase as the seam between them.

Left-to-right pipeline: ~/.openclaw filesystem into watching (watchdog daemon), reading (collectors), writing (supabase.ts to Postgres), rendering (Next.js dashboard), out to an operator with a live view. — The repo as a four-stage pipeline. The watchdog daemon tails ~/.openclaw by file offset, parses every source, and upserts the reconstructed tree into 13 Supabase tables; the Next.js dashboard reads them and subscribes to postgres_changes for a live view. Orange traces one tick of data crossing the seam.