The Dashboard Count of 352 and the Ticket It Wrongly Started

The admin error dashboard showed 352 next to one page, and the ticket filed off that number said it happened 352 times in the past week. That sounded like something had just started breaking badly. It hadn’t.

The query had no window

The query behind that count had no date filter at all. It was a straight lifetime total, grouped by error type. What made it misleading was its neighbor: a “most recent occurrence” column showing a timestamp from that same day. A big number beside a fresh timestamp reads as “this many, just now,” even though the two columns answer different questions.

So we skipped the dashboard’s framing and queried the raw error table directly. The count’s spread went back more than two years, to a specific month in 2024. Spread over that span, it was a slow trickle. Not nothing, but nowhere near the emergency the ticket had been filed as.

Fixing the dashboard instead of the ticket

Explaining the numbers once wouldn’t help, because the dashboard would keep producing the same misleading pair for the next person who looked at it. The fix added a second column: a count of occurrences in just the last seven days. It comes from the same query, using a conditional sum rather than a separate round trip to the database. The old lifetime column got relabeled “All time” so nobody could mistake it for something current.

One page on the live dashboard now reads 142 all-time next to 6 in the last seven days. You can tell at a glance which number matters right now.

The real bug in the same data

While we were in the error table, something concrete turned up. A handful of upload pages were timing out, and the log showed one account retrying the identical file upload roughly ten times over two days, never once succeeding.

The setting that limits how long a script may run was missing from three of these pages. Thirteen comparable pages already had it set. That setting covers more than server-side processing time. It also covers the whole time the server spends receiving the file from the browser, and for a normal phone photo on a slow connection that can run well past a minute by itself. With the setting unraised, the upload dies mid-transfer. Transfer time depends only on file size and connection speed, so the same file fails the same way on every retry, however many times someone tries.

We confirmed it on a test server with a direct comparison: the identical file over an identical slow connection failed with a server error when the setting was unset, and succeeded once it was raised to match the other pages. We fixed all three.

What the 352 was really telling us

A count with no time window gets read in the context of whatever sits next to it. Here that was a recent timestamp, so a backlog more than two years deep passed for an active flood. The change corrected one misfiled ticket. It also meant the dashboard could no longer produce that misreading for the next person who glances at it. Any all-time figure now needs a time-bounded one beside it, and each needs a label that says which it is.

dxdev LESSON · paste into your AI coding agent
LESSON: A Lifetime Count Displayed Next to a Recent Timestamp Reads as Urgent
SOURCE: dxdev.com/blog/a-bug-report-that-was-two-years-old
WHAT HAPPENED: An admin dashboard showed an error count with no date filter, a true lifetime total, positioned directly beside a "most recent occurrence" timestamp. A count of several hundred, sitting next to a timestamp from minutes ago, read as "this many, just now," and got written up and filed as urgent on exactly that reading. Querying the underlying data directly showed the real spread was more than two years, a slow background trickle, not a flood. The fix added a genuinely time-bounded count (occurrences in the last seven days) as its own column, computed in the same query, and relabeled the old column so it could no longer be mistaken for something recent.
THE RULE: Any dashboard number with no explicit time window attached will get read as "right now" by whoever is looking at it, especially when it sits next to a timestamp that actually is recent. A count needs its time window in the label, not just in the query, or it needs a second, actually-bounded number next to it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any displayed count, total, or aggregate with no date/time filter in its underlying query, rendered adjacent to a timestamp or label that implies recency.
  2. Any incident or bug report in the last quarter that was prioritized or escalated based on a raw count from a dashboard, without checking the actual time range that count covers.
  3. Any place a "recent" or "current" metric and a "lifetime" or "all-time" metric share a column or a label, with nothing distinguishing which is which.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.