Dashboard Metric Not Updating? It May Be Typed In by Hand

If a dashboard metric is not updating, check first whether it was ever computed. Many of the tiles that never move are numbers someone typed in once, with no query behind them and no date beside them. The fix is to give every figure an as-of date, and to make anything older than its allowed age say “stale” instead of showing a value.

We found this in our own operation in October 2026. A founder asked why a dashboard said we had published nothing, when we had. The tile was not broken. It was never connected.

Why is my dashboard metric not updating?

Three causes cover most cases: the refresh job failed, the source stopped sending data, or the number was never computed at all. The first two leave a trail in your logs. The third leaves nothing, because nothing ever ran. Start by asking where the figure comes from, not when it last refreshed.

A refreshed dashboard can still be wrong. Refresh tells you the pipe ran. It says nothing about whether a pipe exists for that tile.

What actually happened in our strategy dashboard?

In July 2026 we seeded a handful of metrics on our internal strategy dashboard by hand: posts published per month by founders and team, plus a fitness score. Each row got a current value of zero as a placeholder. Nobody wired the rows to a source, and nobody set a reminder to.

In October 2026 the number was quoted in a planning conversation. It said zero. Posts had been going out the whole time, from a separate publishing tool that holds the real counts. The dashboard database had no posts data at all. The chief-of-staff agent read the row faithfully and reported zero with full confidence.

A reader sees “0” and concludes the team stopped publishing. The truth was that nobody had asked the system that knew.

The row had no timestamp. That was the actual defect. A value with no date cannot be judged, so it gets believed.

How do you tell a typed number from a computed one?

Ask for the lineage of one tile: what query, on what table, run by which job, at what time. A computed number can answer all four. A typed number answers none, and the answer to “when was this last true” is “when someone last remembered.”

Here is the comparison we now use when reviewing any dashboard:

Kind of number	Where it comes from	What breaks	What it must show
Computed	A query run by a scheduled job	The job fails or the source stalls	Last successful run, age
Synced	A copy of a figure from another tool	The sync stops quietly	Source name, last sync time
Typed	A person, once	Nothing breaks. It just ages	An as-of date and an owner

The third row is the dangerous one, because nothing alerts. A failed job pages someone. A number that was always a guess does not.

Vendors have started building this distinction in. Microsoft’s Power BI documentation (updated 2025-2026) says a dashboard’s title menu shows a contact but no timestamp, and that you only get a last-refresh date by opening an individual tile in focus mode or the related-content pane. The same page notes that some content is not scheduled for refresh at all, so you may see empty entries. Even a mature BI tool hides freshness one click down.

What is an as-of date, and what does it fix?

An as-of date is the moment a figure was last true, stored next to the figure. It fixes the blind spot: a reader can now judge the number instead of trusting it. Pair it with an allowed age, and the dashboard can refuse to show a value that has outlived its welcome.

The Google SRE Workbook (2018) describes freshness objectives for data pipelines in plain terms: that the oldest data is no older than some set age, or that a job has completed successfully within some set time. dbt’s documentation (current version) turns the same idea into two thresholds on a source: a warning age and an error age, measured from the newest loaded timestamp.

We borrowed both. Every metric row now carries a value, an as-of date, a source and an allowed age. Past the allowed age the figure stops being displayed as a number. It reads “stale, last true in July”, and the agent that quotes it must say so too.

That last part matters more than the dashboard. An agent that reads a stale row and states it flatly is an error generator. The rule we gave the chief-of-staff agent: never quote a strategy metric without its as-of date, and if the date is older than two weeks, say it is stale.

What else hides inside “a number that cannot be wrong”?

A count can be wrong without being typed. In August 2026 a dry-run report for a data backfill said “zero rows would be replaced” for people who all already had rows. The count was never measured. It summed a flag that only the live path ever set, so every dry run printed zero, whatever the lookup found.

Zero is a believable answer, so it was believed. We spent a debugging cycle on several components that were working fine.

The common thread with the hand-typed tile: a number that cannot be wrong because nothing computes it. Two checks catch it. Ask whether anything writes the field that the count reads. And write a test that fails on the old code, which is only possible if the counter lives in a function a test can reach. An untestable counter is where a constant hides.

What is the fix, and is it done?

The part that held: as-of dates and allowed ages on every metric, a stale state that replaces the value, and the quoting rule for agents. The part still open: the sync from the publishing tool into those three rows. It was specified in October 2026, and as of 25 October I have not verified that it is live, so treat it as unfinished. Until it ships, the stale flag does the job the sync should do, which is why we built the flag first.

Which check can you run this week?

You do not need a new tool. You need one hour and your existing dashboard.

1. Pick the five figures people quote most in meetings.
2. For each, write down the query, the job, and the last run time. If you cannot, mark it typed.
3. Add a visible as-of date to every typed or synced figure. A spreadsheet cell next to the number is enough.
4. Set an allowed age per figure. A weekly number gets eight days. A monthly one gets five weeks.
5. Anything past its age shows “stale” instead of a value, even if that means a red tile.
6. Look for zeros and round numbers. They are the most likely to be constants.

Then repeat in a month. Freshness decays, so a one-time check is only a snapshot. Our post on checking an automation is still working after day one covers the age-of-newest-output check for jobs, and the same logic applies to figures.

For what a full instrument panel should record, see what a company run by agents watches.

Where does this fit?

Every tomte, our word for one production agent with one defined job, reads some numbers and writes others. When a number it reads is typed and undated, it passes the error along at machine speed and in a confident voice. An AI operations audit traces each figure your team and agents rely on back to its source, flags the typed ones, and hands you a written list with owners and allowed ages. You can see the fleet this practice comes from on the agent fleet proof page.

Want your five most-quoted numbers traced? Start async. We reply within one business day, and there are no meetings.