checked Sep 8, 2026 12:08 AM UTC · RIPE NCC's official status page
RIPE NCC Non-Critical Services is slower than normal.
1 of 9 components affected
Statusfield watches RIPE NCC alongside the rest of your stack and tells you when its status changes. Email, Slack, Microsoft Teams, PagerDuty, and webhooks.
Email only. No password. Free.
7 reports published by RIPE NCC in the last 30 days · 1 still open
When RIPE NCC breaks, it is typically resolved in 12h 27m — median across 7 resolved incidents over 90 days.
investigatingSep 7 · 07:33 UTC
The RIS pipeline has stopped publishing update and bview files for RRC24 hosted at LACNIC, Uruguay. This mirrors the issue that affected RRC18 over the weekend. We suspect a common root cause, but it has not yet been identified. We cannot rule out other RRCs experiencing the same issue in the coming hours or days.
Reported by RIPE NCC on their status page.
resolvedSep 7 · 07:19 UTC
The problem with RRC18 was resolved by restarting two services running in the backend, however the root cause is not clear yet. We keep troubleshooting. A similar problem is now affecting RRC24 at Montevideo, Uruguay.
Reported by RIPE NCC on their status page.
resolvedSep 4 · 16:06 UTC
This incident has been resolved.
Reported by RIPE NCC on their status page.
resolvedAug 27 · 14:21 UTC
This incident has been resolved.
Reported by RIPE NCC on their status page.
resolvedAug 24 · 14:00 UTC
This incident has been resolved.
Reported by RIPE NCC on their status page.
resolvedAug 18 · 14:45 UTC
A fix to an internal backend was deployed at around 13:30 CEST and the issue has not reappeared since. We are working on extra monitoring to prevent issues of this type from affecting measurement scheduling in the future.
Reported by RIPE NCC on their status page.
postmortemAug 13 · 13:02 UTC
Between approximately 00:06 UTC on Sunday, 2 August 2026 and 12:30 UTC on Tuesday, 4 August 2026, there was an issue affecting the RIPE Database NRTM mirroring service. The root cause was an invalid RPSL object being added to the RIPE Database, which in turn caused the NRTM service to stop working when it reached this object. This invalid response caused NRTM clients to desynchronise from the RIPE Database from this point onwards. A code change was introduced in Whois release 1.122 in April, which inadvertently allowed additional newlines in “descr:” and “remarks:” attributes. This resulted in an invalid RPSL object being written in the database. We have changed the UTF-8 code point substitution to no longer write additional newlines. Additionally, the NRTM server did not skip over invalid RPSL objects, but failed with an “internal error occurred”. We have now changed this behaviour to skip invalid RPSL and log an error. If this happens in future the DB team will take action to correct the invalid RPSL so the update will appear later in the NRTM stream. Both of these issues will be fixed in the upcoming Whois 1.124 release, due on Thursday, 27 August 2026. We have also improved the monitoring of the NRTM service, which will now also request a recent range of updates from the NRTM server and validate the response.
Reported by RIPE NCC on their status page.
