# Data Freshness: The Failure a Schema Check Cannot See — Routebase

> A field that keeps its shape and stops changing its value passes every validation perfectly, which is why staleness needs its own kind of check and its own kind of judgement.

Canonical page: https://routebase.dev/guides/api-monitoring/api-data-freshness-monitoring/
Chapter 8 of 9 · API Monitoring · Last reviewed 2026-09-13 · The Routebase Team

Contract validation catches a field that changes shape. It has nothing to say about a field that keeps its shape perfectly and stops changing its value, which is a real outage for whoever depends on the number.

## Four failures that pass every check

Each of these returns a `200`, in the usual time, with a body that validates against the contract without a single deviation.

A `lastUpdatedAt` that has read the same timestamp since Tuesday, because the job that refreshes it died. A price feed still serving the numbers from before the upstream provider stopped answering. A counter that stopped counting while its shape stayed an integer. A cached aggregate that got pinned by a deploy and now serves last month's figures to everybody.

The common shape is that the response is structurally perfect and semantically dead. No amount of schema strictness reaches any of it, because the schema describes what the field looks like and never what it should say.

## Why a staleness threshold is the wrong instrument

The obvious fix is a rule that fires when a value has not changed for some period, and it does not survive contact with a real response body.

Most of a response is supposed to stand still. A currency code, a plan name, a warehouse identifier and a configuration flag are all constants by design, and a threshold has no way to distinguish them from a feed that died. Setting one produces a stream of alerts about fields that are working exactly as intended, which is the fastest known way to get an alerting channel muted.

What is left is genuinely a judgement call, and the person holding the context is the only one who can make it. The useful design therefore reports the observation plainly, which is that this path has now returned the same value for forty-seven checks, and leaves the verdict where the knowledge is.

## Pick a handful of fields

Freshness watching pays off precisely because it is narrow. Three questions select the fields worth the effort.

**Is standing still the failure mode?** A timestamp that should advance, a counter that should climb and a feed value that should move all qualify. A status enum that sits on `active` for months does not.

**Does something upstream feed it?** Values that arrive from another system are the ones that go stale silently, because their failure happens outside anything you are watching.

**Would anybody notice within a day?** A field that a nightly report reads is a candidate, while one that a dashboard displays live has a human watching it already.

Two or three paths per monitor is usually the right number. A monitor with twenty watched paths produces a wall of unchanged values that nobody scans, and that is functionally the same as watching none.

## What else a monitor cannot judge

Freshness is one case of a wider limit, and it is worth being explicit about where automated checking stops.

| Failure | Detectable from the response alone |
|---|---|
| A field disappeared | Yes, the contract says it should be there |
| A type changed | Yes, the contract says what it should be |
| A value stopped changing | Yes, across checks, though the meaning needs a person |
| A list came back empty | Sometimes, if empty is never correct for that request |
| A number is plausible and wrong | No, because nothing says what the right number was |

The last row is where monitoring hands over to testing. A test can set up known data and assert a known answer, which is exactly the thing a production monitor cannot do without writing to your live system. [Functional API tests](/guides/api-testing/functional-api-tests/) covers how to pick those assertions.

## In Routebase

The **Field freshness** card on a monitor's detail page watches specific JSONPaths across checks. You enter one path per line, up to twenty per monitor, and each one then reports what the checks have actually seen rather than a verdict.

_Screenshot: Each path reports what was observed, so an unchanged value is stated neutrally and only a path that resolved to nothing is raised as a warning._

There is deliberately no staleness threshold and no alert, because a value unchanged for two hundred checks may be a frozen feed or a perfectly correct constant and only you know which. The one state shown as a warning is a path that did not resolve at all, since that means the watch is measuring nothing.

Two details keep the numbers honest. Freshness is read from the full response body rather than from the truncated sample kept for triage, so a field past the cut does not read as missing forever. It is also recorded whenever the server answered as expected, including on a strict monitor whose check was failed by drift. A drifting endpoint therefore keeps its freshness history exactly while somebody is looking at it. See [Monitors](https://docs.routebase.dev/monitors/).

## Frequently asked questions

### What is API data freshness monitoring?

Freshness monitoring watches the value of specific fields across successive checks and reports how long each one has been standing still. It exists because schema validation only judges shape, so a timestamp frozen since Tuesday and a price feed whose upstream job died both pass validation while being completely broken. The unit of measurement is change over time rather than correctness of a single response.

### Why not just alert when a value has not changed for an hour?

Because a value that has not moved is not evidence of anything on its own. A currency code, a plan name and a configuration flag are all supposed to sit still, and a threshold cannot tell them apart from a dead feed. Only somebody who knows the field can say which one it is, so the honest design reports the observation and leaves the verdict to a person.

### Which fields are worth watching for freshness?

The handful where standing still is itself the failure, which usually means timestamps that should advance, counters that should climb, and values that come from an upstream feed. Watching every field is wasted effort, because most of a response is supposed to be stable and a wall of unchanged values is indistinguishable from no information at all.

### Can a monitor detect wrong data?

It can detect several classes of wrong without knowing your domain, including a value that stopped changing, a field that disappeared from the response, and a shape that no longer matches the contract. What it cannot detect is a number that is plausible and incorrect, because nothing in the response says what the right answer was. That gap is what makes a handful of well-chosen assertions worth more than a hundred generic ones.

---

[Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.