All Systems Operational
RIPE Database
Operational
Email to/from the RIPE NCC
Operational
K-root/DNS
?
Operational
LIR (Member) Portal
Operational
RIPE NCC Access
Operational
RPKI
Operational
RPKI Dashboard
Operational
RRDP Repository
Operational
rsync Repository
Operational
Publication as a Service (API endpoints)
?
Operational
www.ripe.net
Operational
Reverse DNS
Operational
Non-Critical Services
Operational
Billing & Payments
Operational
RIPEstat
Operational
DNSMON
Operational
Mailing Lists
Operational
RIPE NCC Academy
Operational
RIPE NCC Certified Professionals
Operational
RIPE Atlas
Operational
RIPE Labs
Operational
RIS (Routing Information Service)
Operational
Meeting Software
Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
No data exists for this day.
had a major outage.
had a partial outage.
Scheduled Maintenance
RIPE Database HTTPS Configuration
Oct 16, 2024 06:00-07:00 UTC
We plan to apply configuration changes affecting the HTTPS protocol for the RIPE database services. We do not expect any service downtime (queries or updates).
Posted on Oct 08, 2024 - 14:25 UTC
Posted on Oct 08, 2024 - 14:25 UTC
RIPEstat Backend Database Migration: Reduced Availability to Historical Data for Some Datasets
Oct 16, 2024 08:00-11:00 UTC
Last month, we announced that we are preparing for a migration of the database systems behind RIPEstat to a new cluster. After facing several issues, we decided to temporarily postpone the migration since a lot of historical data would not be available. This would have a significant impact on internal and external users that actively use this historical data.
After mitigating several of these issues, on Wednesday, 16 October, we will continue with the migration. This will require a downtime of two hours. During this downtime, we will do an internal evaluation to confirm that everything works as expected. *Please note that there will be an impact on the data that is available*. The data will not be lost, however, data for some periods will not be available until we finish our backfill process.
If we face any unexpected issues, we will re-attempt to complete the migration on Thursday, 17 October.
## Our Steps So Far
We have transferred and backfilled as much historical data as possible. However, a long history (which is for example used to trace the history of legacy resources before they can be sponsored) for the needed datasets is available.
Compared to our previous update, we have been able to transfer the full history of multiple datasets. However, two of the datasets do not have their full history. The API-calls that are using datasets that have reduced history are:
* bgp-state, bgp-updates, bgplay: data is available for the last three months.
* asn-neighbours (API only, widget is unaffected), asn-neighbours-history: data is partially available.
* beginning - 31-12-2011: available
* 1-1-2012 - 31-12-2012: unchanged, unavailable
* 1-1-2013 - 31-12-2020: available
* 1-1-2024 - current: available
Compared to the previous update, we have transferred the full history for one table and imported most historical data for ASN neighbourhood information. We are now filling in the missing historical data for ASN neighbourhood data. Our best current estimate is that *this process will take 36 days*.
Please let us know if you have use cases for a long history of bgp-state/bgp-updates/bgplay data. Depending on the input we receive, we will decide how far, and with what priority, we backfill this data.
Posted on Oct 15, 2024 - 16:31 UTC
After mitigating several of these issues, on Wednesday, 16 October, we will continue with the migration. This will require a downtime of two hours. During this downtime, we will do an internal evaluation to confirm that everything works as expected. *Please note that there will be an impact on the data that is available*. The data will not be lost, however, data for some periods will not be available until we finish our backfill process.
If we face any unexpected issues, we will re-attempt to complete the migration on Thursday, 17 October.
## Our Steps So Far
We have transferred and backfilled as much historical data as possible. However, a long history (which is for example used to trace the history of legacy resources before they can be sponsored) for the needed datasets is available.
Compared to our previous update, we have been able to transfer the full history of multiple datasets. However, two of the datasets do not have their full history. The API-calls that are using datasets that have reduced history are:
* bgp-state, bgp-updates, bgplay: data is available for the last three months.
* asn-neighbours (API only, widget is unaffected), asn-neighbours-history: data is partially available.
* beginning - 31-12-2011: available
* 1-1-2012 - 31-12-2012: unchanged, unavailable
* 1-1-2013 - 31-12-2020: available
* 1-1-2024 - current: available
Compared to the previous update, we have transferred the full history for one table and imported most historical data for ASN neighbourhood information. We are now filling in the missing historical data for ASN neighbourhood data. Our best current estimate is that *this process will take 36 days*.
Please let us know if you have use cases for a long history of bgp-state/bgp-updates/bgplay data. Depending on the input we receive, we will decide how far, and with what priority, we backfill this data.
Posted on Oct 15, 2024 - 16:31 UTC