Dashboard Numbers Need a Date and a Source
Every number on a dashboard should answer two questions before anyone acts on it: which period does it cover, and where did it come from. A figure with no date and no source is a rumor with a font.
Updated-at is not the reporting period
A sync timestamp tells you when the system last wrote to the database. The reporting period tells you which days of activity that row describes. These are different facts and they belong in different places on the screen.
Put the period next to the value, for example a label reading March, or a date range. Put the last successful sync in a quieter status area, with the source named. When a viewer sees a number that looks wrong, the first useful question is whether the period is wrong or the sync is stale, and the layout should let them answer that without opening a support ticket.
If a dashboard mixes periods across cards, say so on each card. A monthly total beside a daily total is not a comparison, it is a trap.
Partial imports and the unknown state
An import can finish without being complete. A source export may cover only part of the period, a scheduled job may have run before the source closed its books, or a seat may have been disconnected for several days.
Treat unknown as its own state, distinct from zero. Zero means the period was measured and the activity was nil. Unknown means the period was not measured, or was measured incompletely. Rendering unknown as zero quietly invents a fact, and people make decisions on it.
A practical pattern is a completeness flag per period per source, shown as a small marker beside the value. When the flag is partial, the number can still display, but with a visible qualifier and a note about which days are missing.
Totals must reconcile with drilldowns
If a total is computed from one query and the drilldown from another, they will eventually disagree. Decide which one is authoritative and derive the other from it, or compute both from the same stored rows.
Show the count of underlying records next to the total, so a viewer can see whether a total covers the rows they expect. When a filter is active, state the filter in the total's label rather than leaving it implicit.
Disagreement between a total and its parts is a defect, not a rounding quirk. It should be caught before a viewer notices it.
A hypothetical labeling decision
Suppose an agency dashboard shows creator hours for the current month. The team debates whether to display the sync time as the primary timestamp, because it is always fresh and always present.
The alternative is to display the period as the primary label and the sync time as secondary status. The test is simple: hand the screen to someone who did not build it and ask them what days the number covers. If they hesitate, the label has failed, regardless of how accurate the underlying data is.
This is a design decision with a tradeoff. Period-first labeling takes more space and forces the team to define period boundaries explicitly. Sync-first labeling is easier to implement and answers a question almost nobody asked.
Acceptance tests you can run
Test one: open the dashboard with the source disconnected. Every affected value must show unknown or stale, not zero, and the source status must be visible without scrolling to a settings page.
Test two: pick any total, open its drilldown, and sum the visible rows. The two must match exactly, or the difference must be explained on screen. If they differ silently, the dashboard fails.
Test three: ask a colleague who did not build the page to state the reporting period of three different cards. Any wrong answer means the labeling is insufficient.
Test four: simulate a partial import covering part of a period. The value must carry a visible qualifier naming the missing days. A clean-looking number over incomplete data is a fail.
Tradeoffs to accept up front
Clear labeling costs screen space and adds states to the interface. Teams that skip it usually pay later in mistrust, when people stop believing any number on the page.
There is also a maintenance cost. Period definitions, source names, and completeness rules must be documented, because the person who built the sync will not always be the person debugging it.
The payoff is narrower than it sounds. A well-labeled dashboard does not make decisions for anyone. It simply ensures that when a decision is made, it rests on a number whose date and origin are known.
Continue reading
A practical next step
Explore the related Devign work, then discuss your requirements before committing to a project scope.