Data Freshness Is an SLA: The Logic of Never Sending a Report on Stale Price Data

Why is data freshness an SLA? A correct but old price is as dangerous as a wrong one — we explain how Senkrondata verifies freshness before every report.

A price report can contain correct numbers and still be completely misleading — if those numbers are three days old. Stale data is as dangerous as wrong data; arguably more dangerous, because it looks correct. A customer sees "competitor price unchanged" in the report and relaxes — when in reality the data simply wasn't updated that day.

That's why data freshness isn't a "nice to have" feature — it's a service level that must be measured and guaranteed.

Why freshness is fragile

Over 200 channels, each on its own cron schedule, each pulling from its own source. At this scale, something breaking isn't the exception, it's the expected state: a site changes its design, a crawler gets blocked and returns empty data, a network error skips a day. The problem isn't the breakage itself — it's that breakage leaks into a report unnoticed.

And once a report has gone out to a customer, "actually the data wasn't current" is an apology that comes far too late.

How freshness is measured

The freshness check reduces to a simple question: how old is the latest observation the data behind this report is based on? Before every report is generated, the last-updated timestamp of the data it's built on is checked against an expected freshness window (say, "within the last 24-48 hours").

This check runs per channel — because each channel has its own collection cadence and its own risk profile. One channel being stale doesn't mean the others are; the check is scoped accordingly.

Guard logic: stop before sending

The most critical design decision: if the data isn't fresh, the report is not silently sent in its stale form. Instead, the process halts and an alert goes to the relevant team — "this report's data isn't at the expected freshness, it wasn't sent." This is a deliberate design that prefers not sending a report at all over sending a wrong one.

This is the same logic as the "prefer a missed match over a wrong match" principle in product matching, applied to reporting: stopping to raise a flag is safer than silently delivering something you're not sure about.

Why freshness as an SLA matters

• It builds trust. The customer knows every report they receive has passed a freshness check — that answers "can I trust this number?" up front.
• It catches problems early. When a channel's data flow breaks, the guard catches it the same day, instead of a customer noticing weeks later.
• It clarifies accountability. If a report is delayed, the reason is known: which channel, which data window was missing — not a guess, a recorded reason.

The principles that keep it trustworthy

• Freshness is measured separately from correctness. A number can be mathematically correct but wrong in time — the two need separate checks.
• There's no silent delivery. A report doesn't automatically go to the customer if the freshness threshold isn't met.
• An alert brings in a human. When the guard halts a report, that's not an "error" — it's a moment a human needs to decide on.

The bottom line

A price report's value depends as much on when it's from as on the accuracy of its numbers. A guard mechanism that measures freshness like an SLA and halts the report when the threshold isn't met prevents the "correct but old" trap — and lets the customer read every report with confidence.

If you want your reports to always be built on fresh data, talk to the Senkrondata team.