Skip to main content
TACAVAR
Build in Public

Your Grafana Dashboard Is Lying: 59 Traces

Grafana dashboard anti-patterns: OpenTelemetry trace auditing and Prometheus missing metrics that render as healthy panels. Tacavar Ops catches them.

I probed our Grafana stack. 59 of 59 traces were the same 250ms heartbeat. Not a single agent run, LLM call, tool call, or task outcome. The dashboards looked healthy. The panels were rendering. The latency heatmaps were tight. The bar charts were populated. And the system was empty. That is the most dangerous state an observability stack can be in: not broken, but convincingly blank.

The Dashboard Looked Healthy and Was Empty

We had stood up a Tempo + Grafana + OpenTelemetry stack with three dashboards: Bailian Team Overview, Paperclip Swarm Observability, and Tacavar Ops. Traces were flowing. Panels were styled. If you glanced at the wall, you would assume agents were working. But when I probed the actual query results, every trace in the last hour was paperclip_handle_heartbeat, the 60-second cron polling its own work queue. The tracing pipeline was working. The application was not instrumented. For a founder/operator, that distinction is the difference between a quiet feature and a dead one. The dashboard looked healthy and was empty.

Probing the Actual Query Results, Not the Panels

Never trust the rendered output alone. Run the query and count the rows. That is the first rule of opentelemetry trace auditing. In Tempo, I grouped spans by operation and counted. One operation, 59 spans, all heartbeat. In Prometheus, I ran the exact expressions behind the Bailian Team Overview panels: agent_calls_total, agent_tokens_total, agent_cost_usd_total. All returned no series. They do not exist. Yet the panels gracefully rendered as empty styled timeseries. No error, no red, no missing-data scream. Just a clean line that looked like low traffic. This is one of the most common grafana dashboard anti-patterns: treating visual polish as data provenance. A panel is not evidence. The query is evidence. If you cannot inspect the query result set, you cannot trust the panel. So we started probing every panel through the API, not through the UI.

Why Graceful Degradation Is an Observability Anti-Feature

A broken dashboard makes people investigate. A beautifully empty one makes people think their system is working. That is why graceful degradation is an anti-feature for observability. In product UI, falling back to a blank state can be helpful. In an operations dashboard, it is a lie. If a query fails, the panel should fail loudly. If a metric is absent, the panel should say absent. If the trace operation set collapses to a single heartbeat, the dashboard should show a row count warning. Otherwise, you get observability empty panels that pass every visual inspection. The operator sees green, the founder sees usage, and the agent stack is doing nothing. Tacavar ops observability treats dashboards as assertions, not decorations. Every panel must be falsifiable. If it cannot fail visibly, it will fail silently.

Missing Metrics Look Identical to Low Traffic

Prometheus missing metrics are especially cruel. A missing series and a zero value often render the same way. If agent_calls_total was never created, the query returns no data. If the metric exists but no calls happened, the query returns 0. In a panel with a zero baseline or an empty timeseries fallback, those two states are visually identical. You think you are in a quiet period. You are actually missing instrumentation. We hit this directly: the Bailian Team Overview dashboard queried Prometheus metrics that did not exist, while the Paperclip dashboard showed heartbeat traces that did exist. Both looked calm. Only one was real. The fix is to distinguish absence from zero at query time. Use absent() to alert on missing metrics. Use OR vector(0) only for known-zero states. Then add a separate presence check: count the series, not just the values. If agent_calls_total has zero series, that is not low traffic. That is a broken instrumentation contract.

The Row Count Check I Now Run Before Trusting Any Panel

Before I trust any panel, I run a row count check. For Prometheus, I count the number of series returned for each expected metric family. If the count is zero, the panel is guilty until proven innocent. For Tempo, I count spans grouped by operation, service name, and status. I assert that distinct operations are greater than one. I assert that non-heartbeat operations are greater than zero. I assert that expected agents show up as service names. If all traces are paperclip_handle_heartbeat, the row count check returns 1. That is a failed check, even though the panel looks fine. This is not complex. It is a few queries, a threshold, and an alert. But it forces the dashboard to answer a harder question: are we observing work, or are we observing the observer? You can run it manually before a release, or wire it into CI. The important part is that it runs before you make decisions from the panel.

How Tacavar Ops Turns Dashboard Probes Into Routine Checks

Tacavar Ops turns those one-off probes into routine checks. Instead of hoping dashboards are honest, we schedule the same queries an operator would run manually. Tempo trace auditing checks operation diversity, span volume, and service coverage. Prometheus probes check metric family presence, series counts, and label cardinality. Grafana API checks verify that panel queries return non-empty result sets. OpenTelemetry collector checks confirm spans are exported and attributed. If a dashboard panel is empty, we treat it like a failed health check, not a cosmetic issue. That is how you stop grafana dashboard anti-patterns from becoming production blind spots. It also catches the quieter failure mode: agents that were instrumented once, then drifted after a deploy. For founders and operators, this is not observability theater. It is the difference between knowing your agent stack works and assuming it does because the charts are pretty. Tacavar ops observability is built for that assumption gap.

Run Tacavar's observability audit on your agent stack at tacavar.com/ops.