Investigating - The issue is more widespread and there seems to be a global issue with the reachability between Scaleway and many Internet network operator located in Egypt. The same issues of reaching Egyptian ressources are also observed from other (than Scaleway) internet operators. We are still investigating what is causing this issue, and trying to escalate the problem to the Egyptian network operators, but at this point data we have indicated that the issue is global and out of our control
Jan 25, 2024 - 15:35 CET
Update - Our investigation is suggesting that the issue is located on Orange Egypt side, and we are trying to get in touch with them to solve the issue.
Jan 24, 2024 - 10:45 CET
Identified - The issue has been identified, and is located on the provider side, Orange Egypt.
Jan 19, 2024 - 11:21 CET
Investigating - Our network is unreachable from one ( or more ) Egypt internet provider. We are currently investigating this issue.
Jan 19, 2024 - 09:03 CET
Investigating - A power issue occurred in DC2 rack N14, all servers lost power at 08:24 CET. The issue is now fixed for most of the rack and the servers can now be powered on since 08:30 CET.
Servers 90058 to 90075 are still affected and unreachable.
Jan 24, 2024 - 09:11 CET
Investigating - Loss of public connectivity for Dedirack customers hosted in DC2/S206 during 5mn. start : 2024 Jan 21 23:03:29 UTC end : 2024 Jan 21 23:07:09 UTC
Jan 22, 2024 - 09:38 CET
Investigating - We have detected a switch down in dc2, room 103, rack b1 Servers in that rack currently have no public network access and are unreachable. We are currently investigating this issue.
Jan 19, 2024 - 08:58 CET
Update - You can still manage datacenter intervention from your dedibox console, in Housing
Dec 19, 2023 - 17:47 CET
Update - We are continuing to investigate this issue.
Dec 19, 2023 - 16:48 CET
Investigating - Ticketing directed to Opcore datacenters is currently unavailable to our dedirack clients. Our team is currently investigating.
Dec 19, 2023 - 16:48 CET
Investigating - We have noticed that problems with connecting to the dedibackup service can occur. We will get back to you as soon as we have more information on the situation.
Apr 06, 2023 - 12:23 CEST
Elements - AZ
Operational
90 days ago
97.72
% uptime
Today
fr-par-1
Operational
90 days ago
99.38
% uptime
Today
fr-par-2
Operational
90 days ago
99.19
% uptime
Today
fr-par-3
Operational
90 days ago
99.38
% uptime
Today
nl-ams-1
Operational
90 days ago
94.59
% uptime
Today
pl-waw-1
Operational
90 days ago
100.0
% uptime
Today
nl-ams-2
Operational
90 days ago
94.59
% uptime
Today
pl-waw-2
Operational
90 days ago
100.0
% uptime
Today
nl-ams-3
Operational
90 days ago
94.59
% uptime
Today
pl-waw-3
Operational
90 days ago
100.0
% uptime
Today
Elements - Products
Operational
90 days ago
98.62
% uptime
Today
Instances
Operational
90 days ago
94.16
% uptime
Today
BMaaS
Operational
90 days ago
100.0
% uptime
Today
Object Storage
Operational
90 days ago
100.0
% uptime
Today
C14 Cold Storage
Operational
90 days ago
100.0
% uptime
Today
Kapsule
Operational
90 days ago
96.7
% uptime
Today
DBaaS
Operational
90 days ago
93.73
% uptime
Today
LBaaS
Operational
90 days ago
94.48
% uptime
Today
Container Registry
Operational
90 days ago
99.95
% uptime
Today
Domains
Operational
90 days ago
100.0
% uptime
Today
Elements Console
Operational
90 days ago
100.0
% uptime
Today
IoT Hub
Operational
90 days ago
100.0
% uptime
Today
Account API
Operational
90 days ago
99.99
% uptime
Today
Billing API
Operational
90 days ago
100.0
% uptime
Today
Functions and Containers
Operational
90 days ago
99.95
% uptime
Today
Block Storage
Operational
90 days ago
93.58
% uptime
Today
Elastic Metal
Operational
90 days ago
99.81
% uptime
Today
Apple Silicon M1
Operational
90 days ago
100.0
% uptime
Today
Private Network
Operational
90 days ago
100.0
% uptime
Today
Hosting
?
Operational
90 days ago
100.0
% uptime
Today
Observability
Operational
90 days ago
100.0
% uptime
Today
Dedibox - Datacenters
Degraded Performance
90 days ago
99.4
% uptime
Today
DC2
Degraded Performance
90 days ago
98.32
% uptime
Today
DC3
Operational
90 days ago
99.41
% uptime
Today
DC5
Operational
90 days ago
99.87
% uptime
Today
AMS
Operational
90 days ago
100.0
% uptime
Today
Dedibox - Products
Degraded Performance
90 days ago
99.86
% uptime
Today
Dedibox
Degraded Performance
90 days ago
98.95
% uptime
Today
Hosting
Operational
90 days ago
99.97
% uptime
Today
SAN
Operational
90 days ago
100.0
% uptime
Today
Dedirack
Degraded Performance
90 days ago
100.0
% uptime
Today
Dedibackup
Operational
90 days ago
100.0
% uptime
Today
Dedibox Console
Operational
90 days ago
100.0
% uptime
Today
Domains
Operational
90 days ago
100.0
% uptime
Today
RPN
Operational
90 days ago
100.0
% uptime
Today
Miscellaneous
Degraded Performance
90 days ago
100.0
% uptime
Today
Excellence
Degraded Performance
90 days ago
100.0
% uptime
Today
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.
Related
No incidents or maintenance related to this downtime.
Our Database team is scheduling an infrastructure upgrade on PostgreSQL RDB PAR instances. We expect a short downtime on both classic and HA databases. PAR instances will be updated progressively in a 2-hours window. Impact : A few seconds downtime on HA RDB PostgreSQL instances. ~1min downtime on standalone RDB PostgreSQL instances.
Start : 30-January-2024 between 0600Z (0700LT) and 0800Z (0900LT) for PostgreSQL PAR instances Posted on
Jan 23, 2024 - 10:39 CET
Kubernetes Kapsule clusters in the PL-WAW region with public-only endpoints will be migrated to Private Networks.
Network downtime: this migration will result in a temporary network loss of 1 to 10 minutes.
With the new default isolation configuration, worker nodes still have their public IPs to access the Internet. After migrating, existing security groups configuration won’t be overridden and RR wildcard DNS still point to public IPs.
In order to future-proof your infrastructure and harden security, legacy public-only Kapsule clusters (i.e without any private endpoint) will be End of Life as of 18 March 2024.
Ending the deprecation cycle, Kapsule clusters still with public-only endpoints will be migrated to Private Networks over the following weeks. The migrations will happen region per region, in this order: 1. PL-WAW 2. NL-AMS 3. FR-PAR
With the new default isolation configuration offered by Kapsule, your worker nodes will keep their public IPs to access the Internet. After migrating, past security groups configuration won’t be overridden and RR wildcard DNS still point to public IPs.
Warning: during the migration, all pods of the CNI are restarted. The pod network of your cluster will thus be temporarily unavailable for 1 to 10 minutes (depending on the size of your cluster and the CNI you are using).
Kubernetes Kapsule clusters in the NL-AMS region with public-only endpoints will be migrated to Private Networks.
Network downtime: this migration will result in a temporary network loss of 1 to 10 minutes.
With the new default isolation configuration, worker nodes still have their public IPs to access the Internet. After migrating, existing security groups configuration won’t be overridden and RR wildcard DNS still point to public IPs.
Kubernetes Kapsule clusters in the FR-PAR region with public-only endpoints will be migrated to Private Networks.
Network downtime: this migration will result in a temporary network loss of 1 to 10 minutes.
With the new default isolation configuration, worker nodes still have their public IPs to access the Internet. After migrating, existing security groups configuration won’t be overridden and RR wildcard DNS still point to public IPs.
Completed -
The scheduled maintenance has been completed.
Jan 25, 09:00 CET
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jan 25, 07:00 CET
Scheduled -
Our Database team is scheduling an infrastructure upgrade on PostgreSQL RDB AMS instances. We expect a short downtime on both classic and HA databases. AMS instances will be updated progressively in a 2-hours window. Impact : A few seconds downtime on HA RDB PostgreSQL instances. ~1min downtime on standalone RDB PostgreSQL instances.
Start : 25-January-2024 between 0600Z (0700LT) and 0800Z (0900LT) for PostgreSQL AMS instances
Jan 17, 14:04 CET
Resolved -
This incident has been resolved.
Jan 25, 05:51 CET
Investigating -
Incident API GW - FR-PAR From 22:48 UTC to 23:40 UTC, our public API gateway was under heavy load on fr-par and experienced slowness. K8s APIs were more impacted with frequents downtimes during this period. Some other products APIs, had some short periods of unavailability. Situation is now under control and our teams are still monitoring the applied fixes.
Jan 25, 00:00 CET
Resolved -
This incident has been resolved.
Jan 24, 13:50 CET
Update -
We recommend Kapsule users still encountering network issues to restart cilium pods and kubeproxy pods. A Kapsule patch (CCM) will roll out starting today: it will restart all kube-system components. No downtime expected.
Jan 24, 11:17 CET
Monitoring -
A fix has been implemented and we are monitoring the results.
Jan 22, 12:15 CET
Investigating -
The issue is still occurring, we keep on investigating.
Jan 22, 11:54 CET
Monitoring -
The situation should be getting back to normal, we’re closely monitoring.
Jan 19, 14:59 CET
Investigating -
VPC related service unstable on region Paris. The team is currently working to resolve the situation as quickly as possible.
Jan 19, 14:48 CET
Completed -
The scheduled maintenance has been completed.
Jan 23, 09:00 CET
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jan 23, 07:00 CET
Scheduled -
Our Database team is scheduling an infrastructure upgrade on PostgreSQL RDB WAW instances. We expect a short downtime on both classic and HA databases. WAW instances will be updated progressively in a 2-hours window. Impact : A few seconds downtime on HA RDB PostgreSQL instances. ~1min downtime on standalone RDB PostgreSQL instances.
Start : 23-January-2024 between 0600Z (0700LT) and 0800Z (0900LT) for PostgreSQL WAW instances
Jan 15, 19:07 CET
Completed -
The scheduled maintenance has been completed.
Jan 22, 20:00 CET
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jan 22, 10:00 CET
Scheduled -
A migration of the Mimir shards for product metrics is planned by the Cockpit team.
We excepted no interruption on the write path.
Read path will be impacted, no data will be return from 12h before the start of the migration. The data will be available after the migration, queries will be back to normal 12h after the migration.
Jan 18, 14:31 CET
Resolved -
This incident has been resolved.
Jan 22, 13:52 CET
Update -
We are continuing to monitor for any further issues.
Dec 28, 10:54 CET
Monitoring -
A shared ETCD server database error lead to control plane misbehaviours in the fr par region, including potential read only, unexpected node replacement and non functional autoscaling between yesterday (2023-12-27) 18:35 UTC and this morning (2023-12-27) 08:48 UTC The issue is now solved and monitored.
Dec 28, 10:31 CET
Resolved -
This incident has been resolved.
Jan 20, 11:25 CET
Monitoring -
Latencies are back to normal since 16h15 UTC Capacity increase operation is still ongoing on this cluster.
Jan 19, 21:16 CET
Identified -
After investigation, this unusual usage was confirmed legit and so, our team increased the capacity of the concerned AMS-1 block storage cluster to handle it, resulting in a net improvement of the situation. Capacity increase operation is still in progress and should end tonight.
Jan 19, 17:05 CET
Investigating -
We are experiencing an unusually high level of usage on our AMS-1 block storage platform that might cause latency. Actions are in progress to improve the situation.
Jan 19, 12:32 CET
Resolved -
This incident has been resolved.
Jan 19, 13:06 CET
Monitoring -
A fix has been implemented and we are monitoring the results.
Jan 8, 08:24 CET
Update -
We are continuing to investigate this issue.
Jan 8, 08:09 CET
Investigating -
Debian and Ubuntu images aren't available on AMS1/WAW3/AMS3, cannot create instance. Got 404 error on /servers endpoint on creation
Jan 8, 08:00 CET
Resolved -
This incident has been resolved.
Jan 19, 12:53 CET
Investigating -
Device located in DC5 room 7 rack D4 is currently unreachable. All EMaaS servers atttached to mentionned leaf lossed their public internet connectivity. We are currently investigating this issue.
Jan 19, 11:12 CET
Completed -
Maintenance has been postponned in order to perform a full equipment replacement later. A new maintenance will be created at a later date
Jan 19, 12:35 CET
Scheduled -
In a prevention of a hardware failure, we will be replacing a component in room 101 of DC2, impacting racks K15 K16 K17. Servers will be shutdown before the operation and powered on again at the end.
Date : 25/01/2024 - 11AM CET
Estimated time : A maximum of 1 hour
Jan 18, 11:45 CET
Resolved -
This incident has been resolved.
Jan 18, 19:04 CET
Update -
We are continuing to monitor for any further issues.
Jan 18, 19:04 CET
Monitoring -
Slowness has been detected on S3 for PUT operations on the fr-par zone since 4:30pm today. Our teams have already restored the situation, but we will continue to monitor the situation.
Jan 18, 18:40 CET
Resolved -
This incident has been resolved.
Jan 17, 10:12 CET
Monitoring -
The switch has been replaced and servers are now responding properly. We are currently monitoring the situation.
Jan 17, 00:47 CET
Investigating -
We have detected a switch down in DC2 Room 103 rack H4. Servers in that rack currently have no public network access and are unreachable. The team in charge is investigating the issue
Jan 16, 22:26 CET
Completed -
The scheduled maintenance has been completed.
Jan 15, 09:01 CET
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Jan 15, 08:01 CET
Scheduled -
In order to provide the ability to attach IPv6 addresses to Load Balancers, a migration must be performed.
The expected downtime will be about 2 seconds, and existing TCP sessions will be reset.
The migrations will be done between the 15th of January and the 15th of February 2024 at 8 to 9am CET each day
All targeted LBs' owners will receive an email for every single impacted LB, containing the predefined migration timeslot.
If you need your Loadbalancer to be migrated on a specific day, feel free to contact us via the #load-balancer Slack Community channel or via the ticket which will be automatically opened in regards to this migration.
Jan 5, 10:26 CET