Is my data actually fresh? Check "data through", not "last refreshed"
"Last refreshed" tells you that a job ran, not that any new data came in with it. To know whether a feed is current, look at its "data through" date, the date of its newest row, and compare it with how often that feed should deliver.
| Last refreshed | Data through | |
|---|---|---|
| What it dates | The last time the job ran | The newest row the feed delivered |
| Where it comes from | The pipeline's run log | The data itself: call date, sale date, status date, ship date |
| When it moves | Every run, whether or not anything new arrived | Only when new rows arrive |
| What a frozen feed shows | Today, as usual | The day the feed stopped |
| The question it answers | Did the job run? | Is the content current? |
How a feed freezes while every job succeeds
A pipeline checks that its jobs ran, and rarely that they brought in anything new. Common ways a feed stops while the run log stays green:
- A report is renamed or moved. The vendor renames a report or moves it to a new folder or SFTP path. The job finds nothing new where it looks and finishes without an error.
- An empty file arrives. The export returns only a header row. Loading zero rows is not an error.
- The same file loads again. A snapshot feed resends last week's file. Row counts barely move.
- One source drops out. One distributor stops reporting to the data aggregator that sends your sales data. The others keep the feed alive.
In each case "last refreshed" still shows today, and the dashboards show the same numbers under a fresh timestamp. Often the gap comes to light only when someone in the field notices a missing call or order.
Every number in this guide comes from a synthetic dataset. It models a small biotech with one injectable brand, 60 sales territories and about three years of history in four feeds: calls logged in Veeva CRM (customer relationship management system), sales data from six distributors, and hub status and dispense records for patients served by four specialty pharmacies. There are no real patients, prescribers or accounts in it. The data runs through Monday, October 12, 2026, and we checked it the same day.
The data is rebuilt every day with rows through that day, so the feeds are current. That is a shortcut: a real feed checked that morning would run through the day before at best. One distributor sends its sales a week at a time, which Step 4 shows. There is no frozen feed in it, so the failure above is described, not shown.
Step 1: date each feed by its newest row
| Feed | Dated by | Last refreshed | Newest row | Days behind |
|---|---|---|---|---|
| Veeva calls | Call date | Oct 12 | Oct 12 | 0 |
| Sales | Transaction date | Oct 12 | Oct 12 | 0 |
| Hub status | Status date | Oct 12 | Oct 12 | 0 |
| Specialty pharmacy | Ship date | Oct 12 | Oct 12 | 0 |
All four feeds were refreshed in the same run on October 12 and have rows through that day. Here the two dates agree. They matter when they don't. If the sales feed stopped delivering tomorrow, its "last refreshed" date would keep moving with every run, while its newest row stayed put and its days behind grew by one a day.
A feed that bundles several sources is complete only through its oldest source's newest row: if one distributor's data ends on October 6 and another's on October 2, the sales feed is complete through October 2. A page works the same way. It should carry one "data through" date, the oldest among the feeds it uses, here October 12. If one feed fell behind, the page would show that feed's date. The date is then true of every number on the page, and a lagging feed can't hide behind the fresh ones.
Step 2: learn each feed's normal rhythm
| Day | Veeva calls | Sales lines | Hub status changes | Specialty pharmacy fills |
|---|---|---|---|---|
| Sat Sep 26 | 12 | 6 | 0 | 0 |
| Sun Sep 27 | 6 | 0 | 0 | 0 |
| Mon Sep 28 | 141 | 64 | 26 | 104 |
| Tue Sep 29 | 197 | 60 | 7 | 60 |
| Wed Sep 30 | 182 | 66 | 8 | 74 |
| Thu Oct 1 | 180 | 75 | 14 | 62 |
| Fri Oct 2 | 143 | 77 | 11 | 89 |
| Sat Oct 3 | 8 | 6 | 0 | 0 |
| Sun Oct 4 | 5 | 1 | 0 | 0 |
| Mon Oct 5 | 162 | 65 | 29 | 88 |
| Tue Oct 6 | 188 | 71 | 6 | 49 |
| Wed Oct 7 | 197 | 46 | 14 | 37 |
| Thu Oct 8 | 164 | 70 | 14 | 52 |
| Fri Oct 9 | 173 | 74 | 17 | 122 |
| Sat Oct 10 | 10 | 3 | 0 | 0 |
| Sun Oct 11 | 4 | 2 | 0 | 1 |
| Mon Oct 12 | 96 | 27 | 12 | 56 |
A quiet day is not always a quiet feed. All four feeds follow the working week. Calls (each account counted once per day, channel, and live or drop-off) and sales fall to a handful at weekends, and the hub and the pharmacies send almost nothing. Over the last 90 days, the median weekday had 164 calls, 64 sales lines, 17 hub status changes and 61 fills, and the median weekend day had 8 calls, 1 sales line and none of the other two. About 1% of sales units shipped on a Saturday or Sunday. A Saturday with 1 sales line is normal. A Tuesday with 1 would be worth a look.
Holidays run lighter still. Labor Day had 6 calls, 1 sales line, no hub status changes and 2 fills, and Monday, October 12, a federal holiday, had 96 calls and 56 fills against 162 and 98 on a usual Monday. Apart from those two days, no weekday had fewer than 122 calls or 40 sales lines. Fills peak on Mondays and Fridays, either side of a weekend when nothing ships. Real sales data often arrives as a weekly file, so its newest row jumps forward once a week, and hubs and pharmacies send files on their own schedules. Learn each feed's rhythm from its own history, holidays included, before you judge it.
Step 3: set a quiet threshold for each feed
| Feed | Expected delivery | Longest run of days with no rows, last 90 days | Quiet after | Status on Oct 12 |
|---|---|---|---|---|
| Veeva calls | Daily | 0 | 4 days | Current |
| Sales | Weekly | 1 | 10 days | Current |
| Hub status | Daily | 2 | 4 days | Current |
| Specialty pharmacy | Weekly | 2 | 10 days | Current |
A feed is quiet when its newest row is more days behind than its threshold. Start from how the feed is delivered:
- Daily feeds: 4 days. If reps log nothing at weekends, Monday's newest call is Friday's, 3 days behind. After a holiday Monday, Tuesday's is 4. Neither counts as quiet.
- Weekly feeds: 10 days. Say the sales file covers a Saturday-to-Friday week and lands the next Monday. Its newest row is that Friday. On the Monday the next file is due, before it lands, that row is 10 days old and the feed still reads current. If the file hasn't come by Tuesday, the row is 11 days old and the feed shows as quiet. A file that lands on Tuesday needs 11 days, and one that lands on Wednesday 12: a week, plus the days from Friday to the day the file lands. Add a day if a file that is one day late shouldn't raise a flag.
Then test the threshold on your own history. In the example's last 90 days the longest stretch without rows was two days, a weekend in the hub and pharmacy feeds. Sales had none on seven Sundays, and calls had rows every day. Real feeds also have holiday weeks, vendor outages and late files. Set the threshold just above the longest gap that turned out to be normal. Too tight, and it cries wolf every week. Too loose, and a frozen feed hides for weeks.
Step 4: check one level down
| Feed | Sources inside it | Every source has rows through | Longest run of days with no rows, any one source, last 90 days |
|---|---|---|---|
| Sales | 6 distributors | Oct 9 | 3 |
| Hub status | 2: the hub and the pharmacies | Oct 12 | 2 |
| Specialty pharmacy | 4 pharmacies | Oct 12 | 2 |
A sales feed often bundles several distributors, and a dispense feed several pharmacies. One source can stop while the others keep the feed's newest row current. Run the same check per source, and date the feed by its oldest source. In the example, five distributors have rows through October 12. The sixth sends a weekly file covering Saturday to Friday that lands on Monday, so on Monday, October 12 its newest row is Friday, October 9, although its rows are dated every weekday. By its oldest source, the sales feed is complete through October 9: the weekend's and Monday's sales are still missing that distributor's share, which comes with its next file on October 19.
The hub status feed has two sources too: the hub, which reports most of the access steps, and the pharmacies, which report the rest through shipment and therapy. Both are current. No source went more than three days without a row, the Labor Day weekend. Small sources have gaps of their own: the six distributors had rows on 66 to 74 of the last 90 days. A distributor that ships to your sites twice a week needs a looser threshold than one that ships daily.
A freshness check, feed by feed
For each feed, a freshness check should show:
- The newest row, dated by the content, not by the job log.
- The expected cadence, written down: daily or weekly, and the day a weekly file lands.
- Quiet or current, against a threshold set from that cadence and tested on 90 days of history.
- The same for each source inside a bundled feed: each distributor, each pharmacy. The feed is complete through its oldest source's date.
Every page then carries one "data through" date: the oldest among the feeds it uses.
When a feed goes quiet:
- The same day, tell whoever owns the vendor relationship and the load, usually commercial operations or the data lead.
- Before the next report goes out, tell the people who read the affected numbers, such as the brand lead and sales leadership: which feed is behind, and the date its data runs through.
- Don't wait for a rep to notice. The check is there so the home office hears first.
James Waterman builds commercial analytics for small biotech teams. hello@aimlitics.com
Ardlow dates every feed by the rows it delivered, not by the job log, shows that date on its main pages, and tells commercial operations when a feed goes quiet. It runs Step 4 for you as well: it lists each distributor and pharmacy inside a feed, judges each one by its own usual gaps, flags the one that has gone quiet while the rest of its feed keeps arriving, and dates the sales data by its oldest distributor still sending as usual, so a weekly file holds the week open until it lands. Its open demo runs on the same kind of synthetic data.