Agent Operations Dashboard

An owner-only operations dashboard that connects repository health, GitHub work, dashboard tasks, Codex activity, alerts, and analytics without pretending a hosted application can read a private workstation directly.

My role: Product designer, architect, and full-stack developer
Context: Independent project, June 2026 to present
Reading time: 8 min read

Private independent product

Why I needed an operations view

My projects live across repositories, GitHub issues, pull requests, local Codex sessions, and deployment systems. Each source answers one question, but none of them gives me a useful picture of what is active, blocked, stale, or ready for review.

I built the dashboard as a private control surface for that work. It tracks projects and tasks, imports GitHub activity, shows repository health, records alerts, and brings bounded Codex telemetry into the same place. The goal is operational clarity, not another list of disconnected metrics.

Hosted dashboard, trusted local bridge

The hosted Next.js application runs on Vercel and stores dashboard state in Supabase. That environment cannot and should not read files from my Windows machine. Local Codex information therefore crosses a deliberate boundary: a trusted local process reads the permitted summaries, sends a bounded authenticated payload, and leaves the raw local runtime data on the machine.

The browser can request a refresh, but it never receives the sync secret and it never reaches into the local filesystem. A Windows scheduled task keeps the outbound sync process available and a watchdog restarts it when necessary. This split gives the dashboard current information without turning the workstation into a public server.

Turning GitHub activity into work state

Projects are linked to GitHub repositories. The dashboard can import issues and pull requests, attach deterministic source links, and promote work into an in-progress state when an open pull request references the issue. Completed work stays counted in status summaries without crowding the default active queue.

I kept manual tasks alongside imported work because GitHub is not the whole operating model. Some actions are deployment, research, review, or machine-level work. The dashboard needs to preserve their source while still presenting one active queue.

Project and repository records with live GitHub health summaries.
Active, review, blocked, ready, backlog, and completed task views.
Codex session, usage, lock, and finding summaries.
Staleness alerts and task/site analytics without invented seed data.

Owner access is part of the product

The dashboard is private. I replaced the earlier general authentication path with an owner-only passkey flow and protected both pages and server APIs. The first credential is enrolled through a guarded bootstrap process, after which the normal interface only exposes passkey sign-in.

That work forced the security model to be concrete: relying-party handling, signed sessions, credential counters, failure paths, server-only database access, webhook verification, and sync authentication all had to agree. The result is a product I can use from my phone without publishing the underlying operational data.

What's left before I call it finished

The core dashboard is usable, but I still treat it as an active product. The next release is focused less on adding pages and more on making the existing work model reliable enough that I can trust it without cross-checking GitHub.

Finish, test, and deploy the Tasks-page refresh that syncs issues and pull requests when the page opens, keeps completed work out of the default queue, and marks issues as in progress only when an open pull request clearly references them.
Add clearer sync diagnostics for partial repository failures, rate limits, and stale data so a green dashboard never hides a broken source.
Run the owner workflows on phone and desktop as regression tests, especially passkey login, manual task edits, refresh-triggered Codex sync, and recovery after the local bridge stops.
Document the operational recovery path for Supabase migrations, scheduled tasks, webhook secrets, and the local daemon without placing credentials in the repository.

Future work (maybe)

These ideas are deliberately not commitments. I will only add them if the dashboard continues to reduce work instead of becoming another system to maintain.

A dependency view linking issues, pull requests, deployments, and blocked work across repositories.
Runner and deployment health alongside project state, with alerts that point to the failing check instead of showing a generic status.
Longer-term trend views for cycle time, review bottlenecks, and stale work once enough real history exists to make those numbers meaningful.
A broader MCP action surface for safe maintenance tasks, guarded by explicit scopes, audit events, and owner confirmation.

Outcomes

01A deployed private dashboard for repository, task, Codex, alert, and analytics workflows.
02A working GitHub-to-task synchronization path with conservative issue and pull-request linking.
03An authenticated outbound telemetry bridge that keeps direct local file access disabled in hosted production.

What I learned

01A dashboard is only useful when every metric has a source and an action attached to it.
02Hosted and local systems need an explicit trust boundary. Convenience is not a reason to blur it.
03Status automation should be conservative. A wrong automatic transition is worse than a task that needs manual review.