I wanted a dashboard that shows what my AI agents are doing. Not Grafana-level monitoring with metrics and alerts — I already have that. I wanted something I could glance at on my phone and know: which agents are active, what they’re working on, how much they’ve spent today, and whether anything needs my attention.
So I built one in React. A single-page app that connects to OpenClaw’s data and displays it as a clean, mobile-friendly dashboard. It took a weekend to build and has become the first thing I check every morning.
What the Dashboard Shows
Panel 1: Agent Status
A list of all configured agents with their current state: active (green), idle (yellow), error (red). Each agent shows its last activity timestamp and a one-line description of what it did most recently. I can see at a glance that the morning briefing agent ran at 8:00 AM, the monitoring agent checked servers at 8:15 AM, and the email agent is idle waiting for new messages.
Panel 2: Today’s Activity
A timeline view of all agent actions today. Color-coded by type: blue for AI model calls, green for tool executions, orange for user interactions, red for errors. Scrollable. Shows the most recent activity first.
This is where I spot problems. A cluster of red entries means something is failing repeatedly. A gap in the timeline means an expected job didn’t run. An unusually long blue bar means an API call took way longer than normal.
Panel 3: Cost Tracker
Today’s running total, compared to the daily average. Broken down by model and by agent. A mini bar chart showing the last 7 days for trend comparison.
Panel 4: Attention Required
Items that need my input: email drafts waiting for approval, flagged moderation items, failed tasks that need review, budget alerts. Each item has an action button: approve, dismiss, or view details.
This panel is the whole reason the dashboard exists. Everything else is informational. This panel is actionable.
The Tech Stack
Frontend: React with Vite. No component library — just vanilla CSS with flexbox/grid. The entire bundle is under 200KB. Loads instantly, even on mobile over cellular.
Data source: OpenClaw log files, parsed and served by a small Express API. The API reads the logs, extracts the relevant data points, and serves them as JSON. About 200 lines of code.
Hosting: Running on the same machine as OpenClaw. The React build produces static files served by the Express API. No separate web server needed.
Auth: Basic authentication with a single username/password. This isn’t a multi-user application — it’s my personal dashboard. Simple auth is sufficient.
Building the Data Layer
The hardest part wasn’t the React frontend — it was getting clean data out of OpenClaw.
OpenClaw logs are text-based and semi-structured. I wrote a parser that extracts:
– Timestamps for all events
– Token counts from API calls
– Tool names and execution times
– Error messages and stack traces
– Session IDs to group related events
The parser runs every 30 seconds, processes new log entries, and stores the extracted data in a SQLite database. The API queries SQLite, which is fast enough for a single-user dashboard.
Total data pipeline code: about 300 lines of JavaScript. Not elegant, but it works reliably.
The Mobile Experience
I specifically designed this for mobile-first viewing. The layout is a single column that stacks the four panels vertically. Each panel is collapsible — I usually keep Panel 1 and Panel 4 expanded, and collapse Panels 2 and 3 unless I need them.
The key design decisions:
– Large touch targets (no tiny buttons)
– High contrast colors (readable in direct sunlight)
– Minimal data per panel (show the summary, not the detail)
– Pull-to-refresh (natural mobile interaction)
Features I Added Later
Quick actions. From the dashboard, I can: restart OpenClaw, pause/resume specific agents, approve pending items, and trigger manual runs of scheduled tasks. These buttons saved me from SSH-ing into the server for routine operations.
Historical view. A date picker that shows any previous day’s activity. Useful for investigating “what happened yesterday while I was asleep?” scenarios.
Cost projections. Based on the last 7 days of usage, the dashboard projects monthly costs. This projection updates daily and has been accurate to within 10% of actual costs.
What I’d Do Differently
Use WebSockets instead of polling. The dashboard polls the API every 30 seconds for updates. WebSockets would provide real-time updates without the polling overhead. I haven’t bothered to change it because 30-second updates are good enough for my needs, but it’s the obvious improvement.
Add notification integration. Currently, alerts go through Grafana/Slack. Having the dashboard send push notifications directly would consolidate my alert channels.
Start simpler. I over-built the first version with features I didn’t need (per-agent cost breakdown by hour, historical trending charts, log search). The features I actually use daily are: status overview, attention-required items, and quick actions. I could have built a useful v1 in a few hours instead of a weekend.
🕒 Last updated: · Originally published: January 12, 2026