---
title: "Making Dashboard Metrics Honest"
canonical: https://dxdev.com/blog/2026-09-26_honest-workflow-dashboard-metrics/
datePublished: 2026-09-23
---
The labels on the agent work-flow dashboard read like literal window or message counts.

I read them that way, and I went looking for windows the number said should exist.

## What the number actually counted

Some of the run records from that day:

- Two runs, one laying out a zones count and one resolving a stash conflict, both ended as `(timeout after 900s)`.
- A third run, an identity fix, committed the fix, but its last line says `git stash pop` hit a conflict in `lib/chrome_pool.py` and it stopped there.

All three count as dispatched. A count of dispatches is not a count of what is running.

The change I shipped that day was clearer labeling, so the numbers explain what they actually count.

## The same drift, earlier that day

That same day, the hub session I was running shipped infrastructure fixes I had never asked for. Three of them:

1. A browser cleanup that was destroying windows I had just been told to sign into.
2. A gate that duplicated every corrected reply.
3. A live session being silently marked closed.

I read those as the same kind of failure as the dashboard label: some part of the system held a belief about what a window was, and the belief and the real window had drifted apart.

`desk identity` now shows the owning identity and sid for each window the chrome pool leases, in both text and JSON mode.

## Then the browser layer went down

The entire agent browser layer had gone down mid-session. I filed a ticket for the next session.

A count labeled as dispatched can't be mistaken for a count of what is alive.

If you run agents behind a dashboard, take each figure and write down the exact event that increments it. If that event is not what the label says, rename the label until the two match, and put the plain-words explanation next to the number.