As the title suggests, this is what I discovered during testing.The real-time performance of the Looking Glass API data has degraded. with noticeable delays in route updates.
It’s unclear whether this is related to the following update: https://status.ripe.net/incidents/d7q0ym4qml7x
Hi moonteach,
Thanks for your post. Can you give more details on what you observed and when?
There are two causes for looking glass delay:
- Systematic delays — often infrastructure
- Temporary delays — often a peer or (partition) of a collector sending many messages.
We have alerts on delays for part of the data being delayed significantly. But we do not have alerts on the average delay because of the noise caused by data volume.
We see a increase in the 95th percentile delay (this quite reliably excludes temporary delays from a single peer). On top of the delay in this chart there is an up to 15s delay due to caching.
What delay do you see and for what prefix? If you include the sourceapp identifier you send we can also take a closer look based on the requests we see.
Hi ties,
I have multiple upstream ASes for one prefix. My testing method is simple: I revoke a route in one of my upstream ASes and observe the update time of the Looking Glass. By default, I can observe 80 as_paths remaining in this AS.
2026-06-17T10:12:50 Route revoked
2026-06-17T10:14:50 First update, 41 as_paths remaining
2026-06-17T10:19:38 Second update, 1 as_path remaining
Previously, when I used the Looking Glass API, I could see the update of as_path in less than a minute, but now it feels like there is a significant delay.
Previously, when I used the Looking Glass API, I could see the update of as_path in less than a minute, but now it feels like there is a significant delay.
On the metrics I looked at, there seems to be more of a spread in the delay. We will make a change to improve our monitoring soon. In the meantime I can take a better look if you send me one of the prefixes. You can do this by email (both for the sourceapp identifier and for the prefixes - use tdekock@ripe.net - I should have time to investigate on Monday).
Hi ties,
I will conduct new tests and share the logs via email. Thank you.
Hi ties,
I have sent the email. The subject line is: The real-time nature of Looking Glass API routing is reduced.
Sender’s email address: github@moonteach.com
We have an interim conclusion. The delay is caused by caching. There is:
- A shared cache for the python application. This changed from a 15s to 300s cache due to a bug (on 12 June). This was fixed on 18 June.
- A per-node cache for the timestamps of the metadata on our backend systems. This is the data for “the latest timestamp we have data for”. This can cause the time for the latest data to be non-monotonic. However, the data itself is fresh/not cached.
Please confirm if the first issue is fixed. We will work on the second issue, but want to be clear this is purely a cosmetic issue: The data is not delayed - the data is from, or from after, the point in time indicated by .data.latest_time
Symptoms are visible below:
$ ./http_ping.py \
--method GET \
--interval 5 \
--jq '.data.latest_time' \
'https://stat.ripe.net/data/looking-glass/data.json?resource=1.1.1.1/24&sourceapp=http_ping'
Starting to GET https://stat.ripe.net/data/looking-glass/data.json?resource=1.1.1.1/24&sourceapp=http_ping every 5.0 seconds.
Evaluating jq expression for each response body
10:12:22.001: 200 0b - [port:49304] jq="2026-06-23T10:11:08"
10:12:27.002: 200 0b - [port:49304] jq="2026-06-23T10:12:18"
10:12:32.004: 200 0b - jq="2026-06-23T10:12:18"
10:12:37.005: 200 0b - jq="2026-06-23T10:12:18"
10:12:42.006: 200 0b - [port:49304] jq="2026-06-23T10:12:33"
10:12:47.007: 200 0b - jq="2026-06-23T10:12:33"
10:12:52.008: 200 0b - [port:49304] jq="2026-06-23T10:12:33"
10:12:57.009: 200 0b - [port:49304] jq="2026-06-23T10:12:26"
10:13:02.011: 200 0b - [port:49304] jq="2026-06-23T10:12:26"
10:13:07.013: 200 0b - jq="2026-06-23T10:12:26"
10:13:12.014: 200 0b - [port:49304] jq="2026-06-23T10:13:04"
10:13:17.015: 200 0b - [port:49304] jq="2026-06-23T10:13:04"
10:13:22.017: 200 0b - [port:49304] jq="2026-06-23T10:13:04"
10:13:27.018: 200 0b - [port:49304] jq="2026-06-23T10:12:18"
10:13:32.019: 200 0b - [port:49304] jq="2026-06-23T10:12:18"
10:13:37.020: 200 0b - jq="2026-06-23T10:12:18"
10:13:42.021: 200 0b - jq="2026-06-23T10:13:27"
10:13:47.023: 200 0b - jq="2026-06-23T10:13:27"
10:13:52.024: 200 0b - [port:49304] jq="2026-06-23T10:13:27"
10:13:57.023: 200 0b - [port:49304] jq="2026-06-23T10:13:49"
GET https://stat.ripe.net/data/looking-glass/data.json?resource=1.1.1.1/24&sourceapp=http_ping
10:14:02.017: 200 0b - [port:49304] jq="2026-06-23T10:13:49"
10:14:07.013: 200 0b - jq="2026-06-23T10:13:49"
10:14:12.011: 200 0b - [port:49304] jq="2026-06-23T10:14:04"
10:14:17.009: 200 0b - jq="2026-06-23T10:14:04"
^C
Hi ties
Thank you for your reply. I will conduct the test and provide feedback on the results after completion.
Hi ties
After my testing, the first problem has been solved.
Thank you.
Thanks for letting us know and for checking. We were unaware of the impact of the bug when we fixed it.
We will make some changes to caching to make it much less likely that a user gets non-monotonic values. After our next release I expect that requests with 60s in between see a monotonically increasing .data.latest_time.