I built an ops dashboard — then deliberately let it die.
I built a dashboard and a board to watch my agents and crons across three machines. When it stopped earning its keep — blocked-issue silt, an ownership lapse, maintenance outrunning value — I let it go instead of babysitting it. Knowing what to abandon is an ops skill.
I couldn't hold the fleet's health in my head.
Autonomous agents plus roughly two dozen scheduled jobs across three machines.
Is every cron firing? Is every agent healthy? What’s blocked? — questions I wanted to answer at a glance, not by reading raw logs.
The hypothesis was reasonable: a dedicated dashboard plus a status board would give me operational visibility without living in the log files.
So I built the monitoring surface. And it worked — well enough to expose its own weakness. That’s the part worth writing down.
A three-piece visibility layer.
Per-machine dashboards, a task/issue ops board, and cron-wired status items — three surfaces meant to feed one operator a single view of fleet health.
Three pieces fed one operator: per-machine /overview dashboards served over Tailscale, a task/issue ops board tracking routines and infrastructure tickets, and cron-wired status items. The board silted up with blocked and duplicate monitoring issues faster than it produced usable signal, and ownership lapsed after a handoff. Rather than keep polishing a surface nobody trusted, I let the dashboard layer lapse and kept the monitoring signal in Slack and the control plane.
Dashboards
Ops Board
Cron-Wired Items
Underlying Signal
Where Signal Landed
The signal that said "stop."
Apr 29, 2026 status check · verified from the Slack record.
The dashboards themselves worked — deployed per-machine, remote-access and pairing issues debugged and fixed. What failed was the economics: the ops board accumulated blocked and duplicate monitoring issues faster than it produced trustworthy signal, and after a handoff nobody kept ownership. The Apr 29 read was blunt — 25 open, 14 blocked, and the honest admission that the work stopped because ownership wasn’t kept.
A judgment call, not a failure to finish.
I built a real monitoring layer, and it worked well enough to prove it wasn’t worth maintaining. Continuing would have been sunk-cost polishing of a surface nobody trusted — so I stopped.
A working three-piece monitoring layer.
- Per-machine /overview dashboards deployed and reachable over Tailscale.
- Remote-access and pairing issues debugged and fixed.
- An ops board tracking recurring routines and HOL-### infrastructure tickets with owners.
- A monitoring cron exporting ~500 settings daily, alerting to Slack and a board item.
I let it lapse — deliberately.
- The board produced blocked-issue silt faster than usable signal.
- Ownership lapsed after a handoff; trust in the surface eroded.
- I judged a dedicated dashboard cost more than it returned and redirected to Slack + the control plane.
Honest to the record: there's no single "we scrapped it" moment — I stopped investing and let it lapse. The cron-wired items were a byproduct of alerting, never a standalone ops dashboard, and I did not inflate them into one.
Where the signal went.
How the call got made.
Per-machine /overview dashboards over Tailscale, a task/issue ops board with owners, and cron-wired status items. Remote-access issues debugged and fixed.
The dashboards worked. But the ops board began accumulating blocked and duplicate monitoring issues, and the surface got harder to trust than the raw signal it was summarizing.
A status check showed 25 open items, 14 of them blocked routine/monitoring issues, and the honest read that work stopped because ownership wasn't kept after the handoff.
I judged the dashboard had negative ROI — high maintenance, low trust, blocked-issue silt — and stopped investing in it, redirecting the monitoring need to Slack alerts and the control plane.
The valuable part is the decision.
I directed the build, used it, and then made the operator’s call to stop investing in it.
I recognized when a monitoring surface had negative ROI — high maintenance, low trust, blocked-issue silt — and killed it deliberately instead of letting it rot half-maintained. I redirected the monitoring need to Slack plus the control plane rather than defending a tool for its own sake. Building the thing was easy; knowing when to cut it is the skill.