Summary

  • RIPE NCC says a 32k file-descriptor limit stopped the database behind RIS Looking Glass on 8 November 2026. An internal API then occupied every available processing slot, leaving Looking Glass, RIS Peers and other RIPEstat APIs unavailable.
  • The database and API recovered that afternoon, but the data did not catch up at the same instant. At 20:06 UTC, about a tenth of RRC25 peers were still delayed. RIPE NCC estimated recovery around 05:00 UTC on 9 November; the incident remained in Monitoring when this account was filed.

The tiny ceiling that filled a public doorway

RIPE NCC built an observatory for other people’s routes and tripped over the observatory’s own filing cabinet. Its incident record identifies a low configuration limit of 32k file descriptors on the database used by RIS Looking Glass. Once the database ran out, an internal API handling Looking Glass requests consumed all available processing slots. Public requests for Looking Glass, RIS Peers and many other RIPEstat APIs became unavailable. The failure moved from one local limit into a shared service doorway.

That chain is more informative than the word “outage.” A file descriptor is a process handle for an open file or connection; the incident names the limit and the exhausted database, but gives no public count of active handles, traffic spike or changed setting. The API slot exhaustion is the documented second step. No public record yet identifies what raised descriptor demand or why the configured ceiling was 32k.

The first posted notice appeared at 12:51 UTC on 8 November and reported that the first customer ticket had arrived at 00:58 UTC. That is a gap of 11 hours and 53 minutes between a reported ticket and the public notice, not a measured start time for every affected endpoint. At 13:20 UTC, RIPE NCC named the descriptor limit and processing slots. Nineteen minutes later it said the database had recovered, the RIPEstat API was recovering, and throughput was close to normal.

The service returned before its evidence did

The second half of the incident ran on a different clock. The 13:39 UTC update said Looking Glass was replaying BGP messages from previous hours. RIPE NCC’s Looking Glass documentation calls its output near real-time and organises it by route collector and peer. It exposes latest_time and peer timestamps because freshness is part of what a routing observation means. A response that arrives promptly with older observations solves the availability problem while leaving a data-age problem.

At 20:06 UTC, RIPE NCC said roughly one tenth of RRC25 peers remained delayed by a high volume of messages. Its estimate of recovery around 05:00 UTC the next day was a forecast, not a completion receipt. The status page still showed Monitoring and RIPEstat degraded at this account’s capture. The RIS Peers documentation describes a separate endpoint grouped by collector, with historical snapshots aligned to 00:00, 08:00 and 16:00 UTC. That makes collector, peer and observation time the useful units of a recovery claim, not a single green API light.

The affected layer was RIPE NCC’s routing-observation service. Its API recovered while the Looking Glass feed was still replaying. The institution can restore a request path faster than it can restore the time represented by every answer. On 8 November, those were two different victories, and RIPE NCC had publicly certified only the first.