Why a Correct Error Count Still Sent Our Team the Wrong Way

Our dashboard showed a count next to a page name, and next to that count a “most recent occurrence” timestamp from that same day. Someone on our team read the two together and concluded the error was happening right now, a lot.

That reading made sense. It was also wrong. The count was every time that error had ever happened, going back more than two years, added up into one number with nothing on the screen saying so.

Both numbers were correct

Nobody built that dashboard to mislead. The count was accurate. The timestamp was accurate. Neither one said what it actually was. A total with no age on it, sitting beside a timestamp that does have an age, gets read as if the two share that age. It’s a labeling gap, and it’s easy to walk past because each number holds up on its own.

The truth showed up when we checked the current data directly instead of trusting how the dashboard framed it. What we found was a slow trickle spread across two years, not a flood from that morning. Getting there took someone stopping, doubting the framing, and going to look at the raw numbers instead of the summary.

What we changed on the screen

We did not write a note explaining the old number better. A note gets read once, if that, and the same misleading pair would still be sitting there for the next person who glances at the page.

Instead we added a second count next to the first, limited to the last seven days, and relabeled the old count “all time” so it could no longer pass as something current. Now anyone looking at that page sees both numbers at once and can tell which one matters for right now.

What still needs a person

None of this removes the judgment call. A current count still needs a person to decide whether it’s urgent, how to prioritize it, and who looks at it next. What changed is what that person is looking at when they decide. Before, they were deciding from a number that answered the wrong question. Now “how much has ever happened” and “how much is happening lately” each get their own answer, and the decision follows from the right one.

Any number shown to someone who has to act on it needs its age stated in plain sight, not buried in a query nobody reads. If a total and a recent timestamp sit near each other on a screen, ask for a time-bounded number beside them, so nobody has to guess which story they’re being told. And when a number makes you want to move immediately, check its age first. In this case it was two years old.

dxdev LESSON · paste into your AI coding agent
LESSON: A Number With No Stated Age Gets Read As Right Now
SOURCE: dxdev.com/everyday-ai/dashboard-number-with-no-age-on-it
WHAT HAPPENED: A dashboard displayed a total count with no date range attached, positioned right next to a "most recent occurrence" timestamp from the same day. A person reading it assumed the count described that day's activity and filed it as urgent. Checking the real data directly showed the count actually spanned more than two years, a slow trickle rather than a flood. The fix added a second, genuinely time-bounded number next to the first one, and relabeled the original so it could no longer be mistaken for something current.
THE RULE: Any number shown without its own time window will be read in the context of whatever sits next to it on the screen. If a recent timestamp sits beside an unlabeled total, someone will assume the total is recent too.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any displayed count or total with no date range in its own label, shown near a timestamp or word that implies recency.
  2. Any escalation or urgent classification made from a raw number before anyone checked what time span that number actually covers.
  3. Any place a "lifetime" and a "recent" figure share one column or label with nothing to tell them apart.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.