Summary

  • RIPE NCC’s 20 October notice separates the freshness of RIPEstat endpoints and says Looking Glass metadata reports the worst delay among the data it returns.
  • A query made at 18:04:43 UTC produced a latest-data timestamp of 12:13:37 UTC. That is one resource-specific snapshot, not a claim about every peer, resource or endpoint.

A five-hour-old route observation may help explain a trend and still be too old for an automated action. That is why a successful response is not the same as current evidence: the query can be new while the observations are not. RIPE NCC’s 20 October notice said RIPEstat delays varied by endpoint; a Looking Glass response shows the difference between those two clocks.

The notice did not describe a single RIPEstat clock. It said the Looking Glass endpoint should be current for a majority—more than 90 per cent—of its peers, while its metadata indicates the worst delay among the data present. Those two statements belong together. A majority can be current while a smaller part of a result is older; a worst-delay field can warn about that tail without describing every row. RIPE NCC did not publish a universal freshness guarantee or define one threshold that makes every peer “up to date.”

A live query offers a useful, limited test of what the API exposes. At 18:04:43 UTC, a request to RIPE NCC’s Looking Glass API returned successfully, with the response marked uncached. Its query time was 18:04:43 UTC; its latest-data time was 12:13:37 UTC. The gap was five hours, 51 minutes and 6 seconds. The response included 23 collector groups and 345 peer records. The timestamp is the endpoint’s summary of recency; it is not evidence that all 345 records were equally old. The test says nothing about a different prefix, a different endpoint or the full state of RIPE NCC’s network.

That distinction matters because RIPEstat is both a public data interface and the source for its own widgets and user interface. The API is not one dataset with one update schedule. Each endpoint answers a different question, and the documentation says timeliness depends on collection frequency, when a data store updates, processing delay, whether collection and processing work normally, and caching. A successful response tells a user that a request returned. It does not, by itself, establish how recently every underlying observation was collected.

The Looking Glass documentation describes its RIS feed as ordinarily near real time, but it also exposes two different timestamps. A peer’s last-updated value describes when a route last changed; latest time describes when the route was last confirmed. Neither can be substituted for the other. The endpoint also supports a look-back limit, defaulting to 24 hours, that excludes older entries. A user who sees no row therefore needs to know the query rule and observation window before treating absence as proof that a route was absent.

The upstream incident helps explain why this is a data-lifecycle issue rather than a routing-outage report. RIPE NCC’s separate RIS notice listed a problem copying BVIEW files from its storage backend and delayed consumption of messages collected at RRC25. At the time of the update, it said the latest BVIEW files were being published except for RRC25; it also reported delays to RIS update files. The separate RIPEstat incident linked to that issue and warned that endpoints would not all be affected in the same way. Neither notice says that routes disappeared from the Internet or that customers lost reachability.

The operational lesson is modest but important: record the data clock next to the query clock. For a decision based on RIPEstat, retain the endpoint, resource, query time, latest-data time, cache status and the coverage represented by the response. Then compare the data age with the decision’s actual tolerance. A five-hour-old observation may be adequate for a historical trend and unsuitable for an automated action; the relevant threshold belongs to the use case, not to a generic dashboard colour.

RIPE NCC’s status note is useful precisely because it does not collapse the incident into one number. Its “more than 90 per cent” statement gives a service-level orientation, while the metadata warns users about the worst delay. The unresolved question for a reader is not whether the status is true or false. It is whether the particular endpoint and evidence window support the choice being made. Treating those as separate checks preserves both the value of the feed and the limits of what it can prove. Primary sources: RIPE NCC RIPEstat incident, RIPE NCC RIS incident, RIPEstat Data API documentation, Looking Glass endpoint documentation, What is RIPEstat?, timestamped Looking Glass API response, and RIS route collector documentation.