Summary

  • RIPE NCC scheduled its RPKI Dashboard for 21:00–21:30 CET on 3 November 2026, while RIPE NCC Access, the LIR Portal and RIPE Database share a 21:00–21:10 window. The status records are separate and list different affected components.
  • On 23 October, the same two component groups again shared a start time. The Dashboard maintenance was marked completed at 20:07:44 CEST; the access/portal/database maintenance at 20:29:56, a 22-minute gap between notices, not a measurement of user downtime.

Imagine being told that the door opens at 21:10 and the room behind it opens at 21:30. That is the shape of RIPE NCC's two scheduled maintenance records for 3 November. Both begin at 21:00 CET. The RPKI event runs to 21:30 and lists the RPKI Dashboard as its affected component. Its notice says the Dashboard will be unavailable during planned work. The other event runs to 21:10 and lists RIPE NCC Access, the LIR Member Portal and the RIPE Database. It offers a generic maintenance update, without a per-service account of what a member can do during the ten minutes.

Those are not four unrelated icons on a status page. RIPE's hosted RPKI guide says a member uses a RIPE NCC Account linked to an LIR to enter the RPKI Dashboard and manage Route Origin Authorizations, the signed objects that identify permitted origin AS numbers for prefixes. RIPE NCC Access documentation lists the Dashboard as a resource-management destination. A member trying to change a ROA interacts with an access path and an application, even if RIPE reports their maintenance under separate headings.

This is the second pair in less than two weeks. On 23 October, the RPKI Dashboard event and Access/Portal/Database event both had a planned 20:00 CEST start. The first was scheduled until 20:30, the second until 21:00. RIPE marked RPKI work in progress at 20:00, verifying at 20:06:47 and completed at 20:07:44. The access-side record went in progress at 20:01 and was marked completed at 20:29:56. The completion notices were 22 minutes 11 seconds apart.

That October ordering is almost the mirror of November's planned durations. The earlier Dashboard notice closed first, while the access-side notice came later. On 3 November, the access-side window is scheduled to close first and the Dashboard window twenty minutes later. These are four distinct maintenance records and their own clocks, not proof that the same change is being repeated. The October stamps establish when RIPE posted completion for each item. They do not establish an end-to-end minute when a member successfully signed in and edited a ROA.

The component boundary matters in both directions. The November RPKI event names the Dashboard, not RRDP, rsync, the ROA Management API or BGP routing. The access-side event names SSO, portal and database. A status icon for one component cannot certify the whole user path, and a broad heading such as “RPKI System Maintenance” should not be read as a measured outage of every RPKI function. RIPE's public notices are precise about the scheduled windows and sparse about the combined operator test.

There is an easy way to make the record more useful. At the end of each window, publish the actual completion time for every named component and one sentence on whether a member could authenticate, open the Dashboard and submit a ROA change. If publication and retrieval paths have a different state, say so separately. The two clocks can remain separate operationally; the reader still needs a single answer for the task that crosses them.