Summary

  • RIPE NCC’s status page recorded an RPKI Test Environment external-API incident on 17 September 2026: Investigating at 14:22 CEST, Identified at 14:43, Monitoring at 14:45 and Resolved at 14:59.
  • The affected component is explicitly labelled Pilot (RPKI). RIPE NCC’s standing documentation says the test environment is best effort and separate from production by system, dataset, repository, Trust Anchor and API base URL.
  • The public incident entry does not identify the affected pilot operations, the fix or change reference, an incident-specific isolation check, the disposition of requests, the monitoring owner or the review window. A compact recovery credential could close that evidentiary gap without exposing keys, payloads, identities or internal logs.

Analysis

The status page is unusually clear about sequence and unusually spare about closure. At 14:22 CEST, RIPE NCC said it was investigating. Twenty-one minutes later, it said the issue had been identified and a fix was being implemented. Two minutes after that, the page moved to Monitoring, saying a fix had been implemented. At 14:59, after a further 14 minutes, the incident was marked Resolved.

Those intervals are useful, but they need careful names. They are intervals between public updates. The first post is not necessarily the technical onset or first detection. The Monitoring post is not necessarily the instant every changed component was deployed. The final post does not reveal which exit test passed. Treating 37 minutes as a complete repair duration would give the status page a precision it does not claim.

Scope is firmer. The incident title names the RPKI Test Environment’s external APIs, and the affected component is “Non-Critical Services (Pilot (RPKI)).” RIPE NCC separately describes that environment as a best-effort service where beta features may appear first. Its hosted test platform is a mirror on a separate system. Test ROAs do not affect the production dataset; they are published in a different repository beneath a separate Trust Anchor.

The API documentation draws the same boundary from the client side. It offers a pilot base URL at localcert.ripe.net and a production base URL at my.ripe.net, and says a configuration can be tested on the pilot without affecting production data. This standing architecture is strong counterevidence to any attempt to turn the incident into a production-RPKI story.

It is not, however, an incident-specific recovery check. The public record does not say which external endpoint families or operations failed. The management API covers several distinct actions; naming “external APIs” does not tell a user whether a read, a proposed change, a publication request or another pilot action was in scope. Nor does the page state whether requests during the interval were rejected, queued, retried or later reconciled.

That distinction matters even in a test service. A pilot is where operators learn whether automation behaves as expected before they trust it elsewhere. A green status can establish that the operator has closed the incident. It cannot, on its own, tell a client whether an attempted test action definitely failed, might have been accepted, or requires comparison with current pilot state.

The missing object is therefore not a long postmortem. It is a recovery join: one public record that binds the incident identity to a bounded operational scope, the public clock, the applied change or incident reference, a confirmation that the documented test/production boundary held, and an aggregate disposition for in-flight pilot work. It should also say who or which team role owned the monitoring interval, what evidence ended it, and when the public record will be reviewed or corrected.

Such a credential can remain privacy-safe. It need not reproduce API keys, ROA payloads, account names, customer identities or internal logs. “No pilot write queue existed,” “requests in these operation classes returned errors and were not retained,” or “accepted pilot actions through sequence X were reconciled” are materially different operational statements even when all identifiers stay private.

The same discipline protects RIPE NCC. An explicit incident-specific isolation confirmation prevents readers from misreading the absence of detail as evidence of production impact. A named monitoring window prevents “Resolved” from being interpreted as an unexamined status flip. A correction date gives the operator room to improve the record without implying that a full causal investigation was completed inside 37 minutes.

Nothing in the reviewed sources supports a claim about production RPKI, signing or access keys, route origin validation, BGP reachability, data loss or root cause. The evidence supports a narrower conclusion: the pilot incident was publicly closed, while the facts that connect service restoration to user reconciliation remain unjoined in the public entry.

Sources