---
title: "AI agent monitoring dashboard: what 1,238 runs showed"
description: "Which panels an AI agent monitoring dashboard needs, from 30 days of my own agent logs: 127,610 tool calls, 1,238 runs, and where one limit fails."
url: "https://madsalt.tech/blog/ai-agent-monitoring-dashboard/"
author: "Denys Zaichenko"
language: "en"
published: 2026-10-29
---

# AI agent monitoring dashboard: what 1,238 runs showed

TL;DR

I pulled 30 days of logs from the agent setup I build with: 127,610 tool calls and 1,238 finished agent runs. Three things decided what a monitoring dashboard should show. 59% of all tool errors were my own guard rules refusing something, not anything breaking, so errors need two counters. One time limit for every agent is wrong: 21% of my test-first coding agents ran past 12 minutes, against 0% of the code explorers. And 1 in 5 agent launches was refused before it started, which no "runs per day" chart shows.

I'm Denys, a full-stack and AI engineer. I build with one lead coding session that hands work to specialised agents: explorers, a planner, test-first coders, security and code reviewers. In [what broke in 3,315 agent runs](https://madsalt.tech/blog/multi-agent-orchestration-what-broke/) I counted the failures. This one asks a different question: what belongs on the dashboard?

**Data.** Session logs and the launch ledger of my own setup, 24 September to 23 October 2026. Every number below is computed from them by one script; client and project names are not in the data I used. It is one person's workload, not a benchmark.

## What should an AI agent monitoring dashboard show?

Vendor guides, such as [Grafana's agent observability docs](https://grafana.com/docs/grafana-cloud/observe-and-act/agent-observability/), centre on latency, tokens, cost and errors. My logs say those four are necessary and not enough. Five panels:

1. **Launches: started, refused, finished, failed**, per day.
2. **Errors split into "refused by a rule" and "broke"**, per tool.
3. **Duration and tool calls per agent type**, as a median and a 90th percentile, with a limit per type.
4. **Tokens per run**, which is cost.
5. **What is running now**, with each run's elapsed time against its type's normal range.

The rest of this article is the numbers behind each one.

## How many agent launches never start?

| Launches, 30 days       | Count        |
| ----------------------- | ------------ |
| Launch attempts         | 1,775        |
| Refused before starting | 352 (19.8%)  |
| Busiest day             | 258 launches |
| Median day              | 40 launches  |

My setup checks every launch: whether the brief names the files the agent may change, whether another running agent already holds those files, which model a risky step needs. One launch in five did not pass. A chart of runs counts only the launches that started, so it hides all of them.

## Why do tool errors need two counters?

Across 127,610 tool calls, 6,691 came back as errors: 52 per 1,000 calls. Then I split them by what the error said:

![What the 6,691 tool errors were. 127,610 tool calls in 30 days. Refused by my own guard rules: 3,954; Actually failed: 2,737.](https://madsalt.tech/charts/en/ai-agent-monitoring-dashboard-errors.svg)

*Figure 1. My agent logs, 24 September to 23 October 2026; split by the error text.*

| Tool         | Calls  | Errors | Of them, refused by a guard rule |
| ------------ | ------ | ------ | -------------------------------- |
| Shell        | 50,960 | 4,985  | 2,970                            |
| Edit file    | 28,244 | 743    | 602                              |
| Read file    | 26,348 | 145    | 1                                |
| Write file   | 8,238  | 208    | 195                              |
| Launch agent | 1,719  | 287    | 132                              |
| Web search   | 2,527  | 57     | 0                                |

3,954 of the 6,691 errors, 59%, were my own rules saying no: a command that would skip a check, an edit before a required lookup, a write to a file another agent owns. That number going up means the rules are doing their job or an agent is fighting them. The other 2,737 are real failures: a test that failed, a command that crashed, a page that would not load. On one chart the two mix: a day of many refusals looks like a bad day, when nothing broke.

## Is one time limit right for every agent?

No. I stop a subagent after 12 minutes or 80 tool calls, and the logs show how different the types are:

![Agent runs past a 12-minute limit. % of runs per agent type, 30 days, 1,238 runs. Test-first coder (214 runs): 21; Security reviewer (46): 6.50; Code reviewer (33): 6.10; Browser test runner (38): 5.30; General-purpose (142): 1.40; Code explorer (44): 0.](https://madsalt.tech/charts/en/ai-agent-monitoring-dashboard.svg)

*Figure 2. My agent logs, 24 September to 23 October 2026.*

| Agent type          | Runs | Median minutes | 90th percentile | Past 12 minutes | Past 80 tool calls |
| ------------------- | ---- | -------------- | --------------- | --------------- | ------------------ |
| Test-first coder    | 214  | 6.8            | 17.1            | 45 (21%)        | 66 (31%)           |
| Security reviewer   | 46   | 5.0            | 10.9            | 3 (6.5%)        | 2                  |
| Code reviewer       | 33   | 4.8            | 10.2            | 2 (6.1%)        | 3                  |
| Browser test runner | 38   | 4.3            | 10.5            | 2 (5.3%)        | 2                  |
| General-purpose     | 142  | 3.1            | 6.5             | 2 (1.4%)        | 8                  |
| Architect           | 72   | 5.2            | 8.5             | 0               | 4                  |
| Code explorer       | 44   | 1.9            | 3.4             | 0               | 0                  |
| All 1,238 runs      |      | 4.0            | 11.8            | 72 (5.8%)       | 98 (7.9%)          |

A coding agent that writes a test, runs it, fixes code and runs it again needs more time and more calls than one that reads files. With one limit, the coder gets cut off a fifth of the time and the explorer could hang for six times its normal length before anything notices. The panel I would build shows each type's 90th percentile and flags a running agent that passes its own, not a global number. Before stopping one, I read its last logged action: an agent 15 minutes into a long test run is working, one whose last action was 10 minutes ago is stuck.

## How much does one run cost in tokens?

A median run used 125,828 tokens and the 90th percentile 211,884, counting everything the agent read and wrote. Explorers sat lower (86,389 median), general-purpose agents higher (141,495). Prices change too often to print, so the dashboard should store tokens per run and model, and apply the current price list when it draws cost. What the same work costs on different models is in [how much an AI agent costs to run](https://madsalt.tech/blog/how-much-does-an-ai-agent-cost/).

Of the 1,775 launches, 883 went to the mid-size model, 827 to the largest one, 33 to the newest top model and 32 to others; 54% of the agents were allowed to change files.

## Did the runs that finished actually succeed?

Of 1,238 runs that reported back, 1,172 completed, 64 failed and 2 were stopped. That 94.7% says the agent finished, not that its work was right. In my setup every code change still goes through a security reviewer and a code reviewer, who can send it back; none of that is visible in a run's status. A dashboard can show that a run ended. Whether the result is correct takes a second agent, a test or a person.

## Which tools exist for this?

For a production app with agents talking to customers, hosted tracing tools such as Langfuse, LangSmith, Datadog or Grafana's agent views cover latency, tokens and traces, and some of them can score outputs. For several coding agents on one machine, there are open-source dashboards that read the agents' hook events into a local database. My own numbers come from the logs the setup writes anyway: a launch ledger, one line per launch, and the session transcripts. For a single developer that was enough, and a script over those two files produced every table here.

What a full orchestration view can look like, with an agent map, a workflow builder and cost charts, is in my [multi-agent orchestration dashboard](https://madsalt.tech/work/multi-agent-orchestration/) prototype.

**Limits.** One developer, one setup, 30 days. "Refused by a guard rule" is matched from the error text, so a few errors may be counted on the wrong side. Duration and tool counts come from agents that ran in the background and reported back; agents that ran in the foreground are not in the duration table. Failures could not be attributed to agent types reliably, so they are reported only as a total.

Running agents in production?

Happy to compare notes on what to measure. No pitch.

[Get in touch](https://madsalt.tech/#contact)