Our admin error log sat over its allowed limit for most of a day. That reads as “something just broke.” Nothing had. We had started counting something we had never counted before.
Why the chart looked like an incident
Twelve days earlier, client-side error reporting had gone live on the admin for the first time. It caught JavaScript errors in the browser, not just errors thrown on the server. Before that date the log only saw the server’s side of the story. After it, every error a browser had been quietly swallowing landed in the same log, on the same chart, on the same axis.
The chart could not tell “a new kind of error just started” from “we just started hearing about an old kind.” It showed a bigger number.
The server-side rate had not moved. That was the check that settled it. The whole spike came from the new client-side channel, so the honest read was “we can finally see something we were blind to,” not “something regressed.”
What the new visibility found
That was not a null result. Tracing it ended in three tickets:
The admin’s main script did not parse at all in an old version of Safari. The fix was rewriting two ES6 spots as ES5 and recompiling. Those sessions had been failing with no server-side trace.
The reporter’s duplicate suppression had never worked, so one recurring error inflated the count all by itself.
Error rows never recorded a username, because a local variable shadowed the global.
The broader client-error clusters already had tickets, so those were left alone.
Where it ended
The spike was a measurement change, not an incident, and treating it as a regression would have sent the investigation hunting for a change that did not exist. The three real problems were already there before anyone was counting. Before you page anyone over a number that just jumped, ask whether the thing measured got worse or whether you just got better at seeing it.
AI Skills
Use this lesson with the AI assistant you already use
An internal dashboard's error count jumped the same week a brand-new reporting channel went live, and the jump was entirely explained by the new channel, not by anything getting worse.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: A New Sensor Raises the Count Before It Raises Anything Real
SOURCE: dxdev.com/blog/2026-08-23_error-count-went-up-nothing-broke
WHAT HAPPENED: An internal staff dashboard's error log spiked, the kind of chart movement that reads as an active incident. The cause was that client-side error reporting had gone live for the first time twelve days earlier (11 Aug), so the dashboard started seeing a whole category of browser-side errors it had never been able to see before. The server-side error rate, the only channel that existed before the change, had not moved at all. Checking that one number settled it: the spike was a new sensor coming online, not a new failure. The added visibility was not wasted, though; tracing it ended in three real tickets: an old browser version that couldn't parse the dashboard's own script at all, a duplicate-suppression feature in the reporter that had never actually worked, and error rows that never recorded a username.
THE RULE: Before treating a jump in any monitored count as a regression, check whether the measurement itself changed (a new sensor, a new reporting channel, a lowered threshold) in the same window; a metric that just started measuring more of the world will show a bigger number with nothing underneath it having gotten worse, and conflating the two sends an investigation looking for a regression that isn't there while any real, pre-existing problems the new visibility actually found sit unexamined underneath it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any alert or dashboard threshold that fires on an absolute count without checking whether a new data source, sensor, or reporting path was added in the same window.
2. Any incident writeup that treats "the number went up" as sufficient evidence of a regression without also checking whether the older, pre-existing measurement channel moved.
3. Any newly-added observability channel that hasn't yet had its own findings triaged into separate, named issues rather than folded into "the spike."
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.