Business Systems Need an Expiration Date on Every Report

Every morning, before my publishing system writes a single headline, it asks one question.

How old is the data I am about to use?

Not what does it say. How old is it.

What it checks

Part of my morning run reads a summary of what people typed into the search box on this site. Counts only. Which words, how many visitors. That summary gets rebuilt every morning at 5:40 Central. The writing run starts at 6:05.

Before the run trusts that file, it reads the timestamp stamped at the top of it. If the file is more than 26 hours old, the run does not use it. It rebuilds it first.

This morning the file was 25 minutes old. Fine. Use it.

But the check runs every single day, including all the days it passes. That is the point.

A stale report does not look stale

This is the whole problem.

An old report looks exactly like a new one. Same font. Same columns. Same confident numbers. Nothing on the page turns gray when the information goes bad.

So people act on it. The call list from last Tuesday. The inventory count from before the big order shipped. The price sheet somebody exported in spring. The ad dashboard that quietly stopped syncing three weeks ago and has been showing the same numbers ever since.

Nobody lied. The report was right when it was made. It just kept getting used after it expired.

The web solved this a long time ago

Every time your browser loads a page, the server can attach a header called Cache-Control. One of its settings is max-age. In plain words, it tells everything downstream how many seconds that response stays fresh after it was generated.

After that, caches are not supposed to keep reusing it as if it were fresh.

Think about that. The whole internet runs on the idea that data carries its own shelf life, and that the thing using it checks the label before serving it.

Most small business systems never got that memo. The spreadsheet does not know it is old. The export does not know it is old. The person reading it is busy and assumes it is current.

Put a shelf life on your own reports

You can do this in an afternoon. No new software.

One. Stamp it. Every report, list, export, and dashboard gets a generated-at time somewhere a human will actually see it. Top of the sheet, not buried in a file property.

Two. Give it a max age. Ask how fast the underlying thing changes. A callback list might go bad in a day. A price sheet might be good for a quarter. Write the number down next to the report.

Three. Decide what happens past the line. There are only two honest answers. Refresh it, or refuse to use it. The dishonest answer is to quietly use it anyway because it was handy.

Four. Leave a little slack, not a lot. My line is 26 hours on a file that is rebuilt every 24. That gap lets a job that starts a few minutes late pass without a false alarm, and it still catches a whole missed day.

Five. Make the machine check, not the person. If the rule only lives in somebody's head, it lives there until the busiest week of the year. Then it does not.

Why this matters more once you automate

When a person reads an old report, there is at least a chance they notice something feels off.

An automation never gets that feeling. It will take a number from last month and act on it with total confidence at six in the morning while you sleep. The faster and more hands-off your business systems get, the more each one of them needs to check the date on what it is about to use.

That is not a fancy feature. It is one comparison. Now minus generated-at, against a number you picked on purpose.

It is also the difference between a system you can trust while you are not watching and one you have to babysit.