We went looking for stale dashboards in a running system and found eight of fifty-four carrying a hardcoded date range. One was titled “Last 30 Days” and showed 5 November to 5 December of the previous year. Another said “this month” and was pinned to August.
Nothing had errored. No alert had fired. The panels rendered, the numbers were real, and the titles were confident.
Why this is the default outcome
When a dashboard is built by asking for one, something has to turn “last 30 days” into something a query can execute. The obvious move is to resolve it immediately: today is the fifth, so the window is the fifth of last month to the fifth of this one, and those two dates go into the saved definition.
That is correct exactly once, on the day it was built. Every day after, the panel is a photograph of a window that has moved on without it.
The reason it survives is that nothing about it looks wrong. There is no error state for “this figure is true but about the wrong period”. The chart draws. The number is plausible. The only way to catch it is for somebody to independently know what this month’s figure should be, which is precisely the knowledge they opened the dashboard to acquire.
Storing the question instead
A panel in AnrilX stores a compiled query, and the period in it is a token (last_30_days,
this_month, ytd), not a pair of dates. The window is resolved when the panel renders.
That sounds like a small implementation detail and it is the whole difference. A stored token cannot be stale, because it is not a value. It is an instruction, and the instruction still means what it says a year later.
The same property is why a model in this platform is structurally unable to write a date. Not discouraged from it: unable, because there is nowhere in the query format for a date literal to be written. A capability that has no representation cannot be got wrong.
What else went stale, and how we found it
Once we were looking, the same class of problem appeared elsewhere:
- A saved report whose sort order had never been set, so under paging it could repeat rows on page two and omit others entirely. Nothing about the table looked wrong.
- Widget definitions referencing fields that had since been renamed. These at least had the decency to break, but only because the stored query is re-validated against the live catalogue on every render. Materialise the column list at save time and they would have rendered a plausible number from whatever was nearest.
Each is the same shape: a decision taken once, stored as a value, and never revisited. Each is invisible from the outside.
The rule we took from it
Store the question, not the answer. Anything resolved at save time is a fact about the day it was saved, and the system will not tell you when that day stops being today.
It is worth auditing your own saved views for this. Look for a title containing a relative period and a definition containing an absolute one. Our ratio was eight in fifty-four, in a system actively maintained by people who knew what they were doing.