A stakeholder opens a dashboard, sees a number that looks wrong, and asks the question every data team dreads: "how fresh is this?" Nobody has a confident answer. The pipeline is "running." The last successful job finished at some point. Whether the data behind that chart is five minutes old or five hours old depends on who you ask and which log they check first.
That gap between "the pipeline ran" and "the data is fresh enough to trust" is where most data automation teams get burned. This article walks through how to define a freshness SLA that means something, instrument it so you actually know when you're close to breaching it, and build alerting that catches the slip before a stakeholder does.
Why "Real-Time" Isn't a Freshness SLA
"Real-time" gets used as a stand-in for an actual commitment, and it rarely survives contact with a real system. Every pipeline has latency somewhere: the source system batches its own exports, the network adds delay, a queue holds messages until a worker picks them up, a downstream transform waits for a scheduled window. None of that is a bug. It's just where the time goes.
A freshness SLA replaces "real-time" with a specific, measurable claim: "the most recent completed order will appear in the dashboard within 15 minutes of being placed." That's a promise you can test, alert on, and eventually break in a way everyone can diagnose. "Real-time" is a vibe. An SLA is a number with a unit attached.
Photo by panumas nikhomkhai on Pexels
Start From What the Data Is Used For, Not What's Technically Possible
The instinct is to ask engineering how fast the pipeline can theoretically run, then write that number down as the SLA. That's backwards. A finance reconciliation job that runs nightly doesn't need five-minute freshness just because a message queue could technically deliver it that fast. A fraud-detection feed absolutely does, because the cost of staleness there is real money walking out the door.
Sit down with whoever actually uses the data and ask what breaks if it's an hour late. A weekly report tolerates a lot of slack. A live inventory count feeding a checkout flow tolerates almost none. Let that conversation set the target, not the other way around. An SLA nobody asked for is just extra engineering work with no one defending it when it's inconvenient to hit.
Pick a Freshness Window You Can Actually Instrument
A freshness SLA is only useful if you can measure it continuously, not just check it manually when someone complains. The standard way to do this is to track the age of the newest fully-processed record: current time minus the timestamp of the latest event that made it all the way through the pipeline and landed in the table your dashboard reads from.
That single number, refreshed every few minutes, tells you exactly how far behind reality your data currently sits. It's a much more honest signal than "last job status: success," which only tells you a job ran, not that it finished before your SLA window closed. A job can succeed and still leave you stale if it started late or ran long.
Where Pipelines Quietly Lose Time
Freshness erodes in places that don't show up as failures. A source system's own export batches on a fixed schedule, so no amount of downstream speed fixes a slow upstream drop. A scheduler with a coarse interval adds up to a full interval of latency by design. Retries on a flaky upstream API add delay that never appears in a success log, because the job did eventually succeed.
Backfills are the quiet one most teams miss entirely: reprocessing old data can occupy the same compute and the same downstream tables that new data needs, pushing today's freshness window out while last month's numbers get corrected. If you don't track freshness as its own metric, a backfill looks completely invisible until someone notices this morning's numbers are stale.
Photo by Juan Hernandez Jr on Pexels
Build the Freshness Check Into the Pipeline, Not a Dashboard Bolted On After
The most reliable pattern is to have the pipeline report its own freshness as part of normal operation, not have a separate process poll the destination table and guess. After each run, write the max event timestamp it processed to a small metrics table or push it to whatever monitoring system your team already uses, alongside the job's own success or failure status.
This turns freshness into a first-class output of the pipeline instead of an afterthought someone has to reconstruct from logs during an incident. Tools like Apache Airflow already expose task-level timing you can hook this into, and a metrics backend like Prometheus makes the resulting freshness gauge queryable and alertable without extra plumbing. Trace context from OpenTelemetry can help pinpoint exactly which stage of a multi-step pipeline is where the delay actually accumulates, rather than leaving you to guess between five candidate jobs.
Set Alerting Thresholds That Warn Before You Breach the SLA
An alert that fires only after you've already missed the SLA is a postmortem trigger, not a save. Set two thresholds: a warning level at maybe 70 to 80 percent of the SLA window, and a critical level at the SLA itself. The warning gives someone a chance to catch a slow run, restart a stuck worker, or at minimum give the business a heads-up before the promise is actually broken.
Be deliberate about who gets paged at which threshold. Warnings can go to a low-priority channel someone checks during business hours. Breaches of a genuinely business-critical SLA should page whoever's on call immediately, the same way you'd treat any other production incident under an SLA with real consequences attached. Route both the same way and you'll either get alert fatigue or missed pages, and both erode trust in the system fast.
"Every data team I've worked with has a freshness SLA nobody wrote down and everybody assumes is being met. The teams that stop getting paged at 2 a.m. are the ones that turned that assumption into a number, an alert, and an owner." - Dennis Traina, founder of 137Foundry
Document the SLA Where Both Engineering and Stakeholders Will Actually See It
A freshness SLA that lives only in a Slack thread from six months ago isn't a commitment, it's folklore. Put it somewhere both sides can find without asking someone: the pipeline's own README, a data catalog entry, or a shared doc linked directly from the dashboard itself. State the window in plain language, the metric it's measured against, and what happens when it's missed.
This matters more than it sounds like it should, because the biggest source of freshness disputes isn't usually a technical failure. It's two teams who never agreed on the number in the first place, discovering that disagreement live during an incident review. Writing it down in advance turns a blame conversation into a shared, boring fact both sides already accepted.
Photo by carlos copete on Pexels
What to Do When You Miss the SLA
You will miss it eventually. Source systems change their export schedule without telling you, a scaling event slows a worker pool, someone ships a change that adds an unplanned retry loop. The difference between a healthy freshness practice and a fragile one isn't whether misses happen, it's whether the team treats a miss as data instead of a fire drill.
Log every breach with a timestamp, the duration of the delay, and the root cause once you find it, the same way you'd track any other reliability metric worth trending over time. Teams that follow the Site Reliability Engineering approach to error budgets apply the same thinking here: a freshness SLA with zero recorded misses either means the target was set too loose, or nobody's actually watching it. A handful of understood, logged misses is healthier than a suspiciously perfect record.
Photo by Blue Arauz on Pexels
Alert Routing That Doesn't Wake the Wrong Person
None of this instrumentation matters if the alert lands somewhere nobody's watching at 3 a.m. Whatever paging tool your team uses, from an in-house Slack webhook to a dedicated platform like PagerDuty, route freshness breaches through the same escalation path as any other production incident, with the same on-call rotation and the same acknowledgment expectations. Treating a stale-data alert as a lower tier of incident than an application outage is how it ends up ignored for hours.
Building this instrumentation from scratch across a handful of pipelines is a reasonable weekend project. Building it consistently across a company's entire data automation footprint, with alerting that people actually trust and don't mute, is closer to what 137Foundry's automation engineering team spends most of its time on. If your team is past the point of tracking freshness in a spreadsheet someone updates manually, that's usually the signal it's time to build it properly.
Start With One Pipeline
You don't need a company-wide freshness policy before you start. Pick the one pipeline that's caused the most confusion this quarter, define its SLA with the people who actually use its output, instrument the freshness metric, and set the two-tier alert. Once that pattern works and the team trusts it, extending it to the next pipeline is copy-and-adjust, not a fresh design exercise.
The teams that get paged the least aren't the ones with the fastest pipelines. They're the ones who wrote the freshness promise down, built a way to measure it honestly, and told the alert when to speak up before the promise broke instead of after. For a deeper look at how this fits into a broader data integration strategy, or to talk through what a freshness SLA would look like for your own pipelines, the 137Foundry team is a good place to start that conversation.
