Status impact color legend
- Black impact: None
- Yellow impact: Minor
- Red impact: Major
- Blue impact: Maintenance
Update - Here is a checkpoint following issues within VPC networks in Region FR-PAR that occurred in the last few days.
From Tuesday 25th, a few issues were raised to our customer support involving connectivity issues in VPC networks.
Some cases were self solved by restarting impacted nodes and/or updated IPs/MACs information.
At the time, it did not appear to be out of ordinary issues.
On Wednesday 26th, more cases were raised and escalated, raising awareness of a potential more widespread bug that could disrupt some edge cases customers, engineers were involved to collect data and investigate cases.
At 12:45 CET, one of VPC Edge routers crashed. A priority 2 incident was opened to engage more resources and analysis.
Huge levels of BUM (Broadcast/Unicast/Multicast) traffic cross-AZ and cross-products were also identified.
In an attempt to solve these issues, the impacted VPC Edge router was fixed and re-added to the production pool to ensure enough computing resources were available to handle the BUM traffic.
This reduced the global level of BUM traffic in all impacted VPC, leading us to believe that the situation was under control.
On Wednesday afternoon, more cases of latency and connectivity issues were raised to customer support.
Investigations kept going on and pinpointed some desynchronization issues between VPC Edge routers and information systems that could explain higher BUM level than usual.
Decision to restart VPC Edge routers services in fr-par-2 was made in an attempt to clear inconsistencies and freshen data on the routers.
After a few perturbations, the situation was stable by Wednesday evening.
We kept monitoring BUM levels and decision was made to accelerate a deployment of new devices that was already being prepared (more CPU & memory to avoid saturation of VPC Edge routers in case of failover scenarios).
Thursday 27th, new devices were added in the morning in an attempt to better handle BUM traffic.
While this showed useful (reducing impacts), it did not significantly help globally in reducing BUM levels.
In the afternoon, a workaround was deployed to protect our VPC Edge routers from these excessive BUM traffic.
A rate-limiter was applied, per customer network, to ensure a no saturation scenario on VPC Edge routers and make sure legit BUM traffic was handled with the right priority in the routers.
This actually caused a high reduction of BUM traffic, as we hoped (stopping what we believe was a snowball effect).
On Thursday evening, deployment of the rate-limiter was globally done and operations were stopped to monitor the situation.
One conclusion of the day is that our maintenance model for VPC Edge routers seems to create ripple effects on customer networks (while it was designed to be fully transparent).
Friday 28th, investigations are still ongoing to understand the root causes of the issues, high levels of BUM traffic are supposed to be handled transparently, and desynchronization issues are not an expected behavior.
Data collecting on one of the VPC Edge routers caused a crash around 11:00 CET, causing ripple effects, as we understood the day before.
Data collection and analysis kept going on during the day, including customer debug sessions to better understand some specific cases.
During the afternoon, a human error was made by 15:50 CET causing another VPC Edge router unavailability, but we were able to restore it faster and with fewer ripple effects this time.
So, the current situation is that we were able to significantly reduce BUM levels globally, and we believe these are related to desynchronization issues of our VPC Edge routers (causing “unknown MAC and/or IP” issues, so a broadcast behavior).
These desynchronizations are probably the cause of our maintenance model issues (traffic is not being treated equally/fairly by redundant VPC Edge routers).
Our teams are working on reducing desynchronization issues (short term) and fixing the underlying condition once identified (mid-term).
Decision was made to stop any action on VPC Edge routers for the weekend, so all the investigation work will be done off the routers with the currently collected data to avoid creating more perturbations.
We believe the situation to be stable for almost all customers, but our VPC infrastructure in FR-PAR region cannot be considered in a fully stable condition, and we deeply apologize for this.
We want to assure you that all of our teams are focused on fixing the issues.
We encourage customers to share all collected data with our customer support team if you still encounter issues.
Nov 28, 2025 - 22:13 CET
From Tuesday 25th, a few issues were raised to our customer support involving connectivity issues in VPC networks.
Some cases were self solved by restarting impacted nodes and/or updated IPs/MACs information.
At the time, it did not appear to be out of ordinary issues.
On Wednesday 26th, more cases were raised and escalated, raising awareness of a potential more widespread bug that could disrupt some edge cases customers, engineers were involved to collect data and investigate cases.
At 12:45 CET, one of VPC Edge routers crashed. A priority 2 incident was opened to engage more resources and analysis.
Huge levels of BUM (Broadcast/Unicast/Multicast) traffic cross-AZ and cross-products were also identified.
In an attempt to solve these issues, the impacted VPC Edge router was fixed and re-added to the production pool to ensure enough computing resources were available to handle the BUM traffic.
This reduced the global level of BUM traffic in all impacted VPC, leading us to believe that the situation was under control.
On Wednesday afternoon, more cases of latency and connectivity issues were raised to customer support.
Investigations kept going on and pinpointed some desynchronization issues between VPC Edge routers and information systems that could explain higher BUM level than usual.
Decision to restart VPC Edge routers services in fr-par-2 was made in an attempt to clear inconsistencies and freshen data on the routers.
After a few perturbations, the situation was stable by Wednesday evening.
We kept monitoring BUM levels and decision was made to accelerate a deployment of new devices that was already being prepared (more CPU & memory to avoid saturation of VPC Edge routers in case of failover scenarios).
Thursday 27th, new devices were added in the morning in an attempt to better handle BUM traffic.
While this showed useful (reducing impacts), it did not significantly help globally in reducing BUM levels.
In the afternoon, a workaround was deployed to protect our VPC Edge routers from these excessive BUM traffic.
A rate-limiter was applied, per customer network, to ensure a no saturation scenario on VPC Edge routers and make sure legit BUM traffic was handled with the right priority in the routers.
This actually caused a high reduction of BUM traffic, as we hoped (stopping what we believe was a snowball effect).
On Thursday evening, deployment of the rate-limiter was globally done and operations were stopped to monitor the situation.
One conclusion of the day is that our maintenance model for VPC Edge routers seems to create ripple effects on customer networks (while it was designed to be fully transparent).
Friday 28th, investigations are still ongoing to understand the root causes of the issues, high levels of BUM traffic are supposed to be handled transparently, and desynchronization issues are not an expected behavior.
Data collecting on one of the VPC Edge routers caused a crash around 11:00 CET, causing ripple effects, as we understood the day before.
Data collection and analysis kept going on during the day, including customer debug sessions to better understand some specific cases.
During the afternoon, a human error was made by 15:50 CET causing another VPC Edge router unavailability, but we were able to restore it faster and with fewer ripple effects this time.
So, the current situation is that we were able to significantly reduce BUM levels globally, and we believe these are related to desynchronization issues of our VPC Edge routers (causing “unknown MAC and/or IP” issues, so a broadcast behavior).
These desynchronizations are probably the cause of our maintenance model issues (traffic is not being treated equally/fairly by redundant VPC Edge routers).
Our teams are working on reducing desynchronization issues (short term) and fixing the underlying condition once identified (mid-term).
Decision was made to stop any action on VPC Edge routers for the weekend, so all the investigation work will be done off the routers with the currently collected data to avoid creating more perturbations.
We believe the situation to be stable for almost all customers, but our VPC infrastructure in FR-PAR region cannot be considered in a fully stable condition, and we deeply apologize for this.
We want to assure you that all of our teams are focused on fixing the issues.
We encourage customers to share all collected data with our customer support team if you still encounter issues.
Nov 28, 2025 - 22:13 CET
Update - From 10:26 CET to 11:11 CET a VPC equipment triggered errors.
You may have seen packet loss during this time.
Nov 28, 2025 - 11:56 CET
You may have seen packet loss during this time.
Nov 28, 2025 - 11:56 CET
Monitoring - Our teams have deployed a fix on FR-PAR-1.
The situation is now under monitoring and stable.
Nov 27, 2025 - 21:37 CET
The situation is now under monitoring and stable.
Nov 27, 2025 - 21:37 CET
Update - Our teams have deployed a fix on FR-PAR-2 and are continuing to work on deploying one on FR-PAR-1 as well.
Nov 27, 2025 - 19:40 CET
Nov 27, 2025 - 19:40 CET
Update - We are still deploying a fix, during this deployement you may see some problems with DNS resolution inside kapsule clusters.
Nov 27, 2025 - 17:49 CET
Nov 27, 2025 - 17:49 CET
Update - We are deploying a fix to stabilize the broadcast traffic.
Nov 27, 2025 - 16:47 CET
Nov 27, 2025 - 16:47 CET
Update - We are still occuring high level of broadcast traffic causing some perturbations. We have a fix being tested at the moment and we will start the deployment in the next hour
Nov 27, 2025 - 15:25 CET
Nov 27, 2025 - 15:25 CET
Identified - In order to stabilize broadcast traffic, we are adding more computing ressources to better handle the load, some maintenances will occur today
Nov 27, 2025 - 11:05 CET
Nov 27, 2025 - 11:05 CET
Monitoring - The maintenance announced in the previous message was not necessary and has been canceled.
We are monitoring the situation.
Nov 26, 2025 - 19:20 CET
We are monitoring the situation.
Nov 26, 2025 - 19:20 CET
Investigating - From 18:00 CET we are restarting a few VPC services on fr-par-1 to fix some edges cases
Nov 26, 2025 - 18:07 CET
Nov 26, 2025 - 18:07 CET
Monitoring - Maintenance completed successfully.
Nov 26, 2025 - 17:36 CET
Nov 26, 2025 - 17:36 CET
Update - From 16:30 CET we will proceed with a restart of some internal VPC services to fix some edge cases, a few perturbation can occur during the restart but should not last.
Nov 26, 2025 - 16:18 CET
Nov 26, 2025 - 16:18 CET
Update - We are continuing to investigate this issue.
Nov 26, 2025 - 15:50 CET
Nov 26, 2025 - 15:50 CET
Investigating - A few customers are still impacted by a few perturbations, the VPC team is working to fix these isolated cases
Nov 26, 2025 - 15:38 CET
Nov 26, 2025 - 15:38 CET
Monitoring - We have noticed a degradation in the performance of the product link to VPC, at 13:58 CET, A fix has been made.
We are currently monitoring the situation.
Nov 26, 2025 - 15:03 CET
We are currently monitoring the situation.
Nov 26, 2025 - 15:03 CET
Identified - We have detected a switch down in Dc5 Room 1 Rack D14
Servers in that rack currently have no private network access and are unreachable.
===================
Thursday 27 november 19h45 UTC
Issue has been forwarded to our team for resolution.
Nov 28, 2025 - 11:17 CET
Servers in that rack currently have no private network access and are unreachable.
===================
Thursday 27 november 19h45 UTC
Issue has been forwarded to our team for resolution.
Nov 28, 2025 - 11:17 CET
Investigating - Following the implementation of new email security measures, it is no longer possible to send messages via SMTP using a sender address that is different from the one used for authentication.
This change is intended to enhance security and improve the deliverability of your emails by preventing identity theft.
If you encounter a 550 ‘Authenticated sender mismatch’ error, please check that the email address configured as the sender in your email client matches the one used to connect to the SMTP server.
Nov 27, 2025 - 13:13 CET
This change is intended to enhance security and improve the deliverability of your emails by preventing identity theft.
If you encounter a 550 ‘Authenticated sender mismatch’ error, please check that the email address configured as the sender in your email client matches the one used to connect to the SMTP server.
Nov 27, 2025 - 13:13 CET
Monitoring - A fix has been implemented and we are monitoring the results.
Nov 26, 2025 - 12:01 CET
Nov 26, 2025 - 12:01 CET
Investigating - We are currently experiencing issues with API connections. This may affect the availability of DNS Management for Elements.
Nov 26, 2025 - 10:39 CET
Nov 26, 2025 - 10:39 CET
[WEBHOSTING] SMTP/51.159.208.135 blacklisted on Microsoft/Outlook from classic webhosting service
Subscribe
Identified - Our service is currently experiencing disruption due to blacklisting by Microsoft.
We are actively working with Microsoft to resolve this issue as soon as possible.
Nov 24, 2025 - 19:34 CET
We are actively working with Microsoft to resolve this issue as soon as possible.
Nov 24, 2025 - 19:34 CET
Update - We are still unable to send SMS to US numbers.
The issue is due to A2P 10DLC regulations, which require registration and approval.
We have submitted the necessary requests to our providers, the approval process takes a minimum of 3 weeks.
We will provide updates as soon as we have more information.
Jul 21, 2025 - 10:30 CEST
The issue is due to A2P 10DLC regulations, which require registration and approval.
We have submitted the necessary requests to our providers, the approval process takes a minimum of 3 weeks.
We will provide updates as soon as we have more information.
Jul 21, 2025 - 10:30 CEST
Identified - The issue has been identified and a fix is being implemented.
Jul 17, 2025 - 15:14 CEST
Jul 17, 2025 - 15:14 CEST
Investigating - We are currently experiencing an issue where messages containing a phone number in the USA are not being properly routed by our SMS provider.
A ticket has been opened on their side.
We are actively monitoring the situation and will share updates as soon as available.
Jul 16, 2025 - 12:15 CEST
A ticket has been opened on their side.
We are actively monitoring the situation and will share updates as soon as available.
Jul 16, 2025 - 12:15 CEST
About This Site
Welcome to the Scaleway Status website. Here, you can view the status of all Scaleway services across all products and availability zones (AZs).
You can check how subscribe, manage your email status updates and how to receive status notifications on Slack here: https://www.scaleway.com/en/docs/account/reference-content/scaleway-status-updates/
Elements - Products
Degraded Performance
Instances
Operational
Elastic Metal
Operational
Apple Silicon
Operational
Object Storage
Operational
Block Storage
Operational
Container Registry
Operational
Network
Operational
Private Network
Operational
Public Gateway
Operational
Load Balancer
Operational
Kubernetes Kapsule
Operational
Serverless Functions and Containers
Operational
Serverless-Database
Operational
Jobs
Operational
Databases
Operational
Messaging and Queuing
Operational
Domains
Operational
IoT Hub
Operational
Web Hosting
?
Degraded Performance
Transactional Email
Operational
IAM
Operational
Observability
Operational
Secret Manager
Operational
Environmental Footprint
?
Operational
Developer Tools
Operational
Account API
Operational
Billing API
Operational
Edge service
Operational
Elements Console
Operational
Website
Operational
Generative API
Operational
Managed Inference
Operational
Elements - AZ
Operational
fr-par-1
Operational
fr-par-2
Operational
fr-par-3
Operational
nl-ams-1
Operational
nl-ams-2
Operational
nl-ams-3
Operational
pl-waw-1
Operational
pl-waw-2
Operational
pl-waw-3
Operational
Dedibox - Products
Operational
Dedibox
Operational
Hosting
Operational
SAN
Operational
Dedirack
Operational
Dedibackup
Operational
Domains
Operational
RPN
Operational
Dedibox Console
Operational
Dedibox VPS
Operational
Dedibox - Datacenters
Degraded Performance
DC1
Operational
DC2
Operational
DC3
Operational
DC5
Degraded Performance
AMS
Operational
DC4
Operational
Miscellaneous
Operational
Excellence
Operational
BookMyName
Operational
Saagie - Products
Operational
Product-1-ACO
Operational
Product-2-BOU
Operational
Product-3-BV
Operational
Product-4-DN
Operational
Product-5-MAT
Operational
Product-6-SIPDEV
Operational
Product-7-SIPINT
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
[Kapsule] Update images system Dec 1, 2025 09:00 - Dec 12, 2025 09:00 CET
We are introducing a new image system for Kubernetes Kapsule clusters, bringing significant improvements, including reduced boot time, faster autoscaling, and an updated Ubuntu version.
The advantages of the new image system include improved boot time, reduced from over five minutes to under one minute, and faster autoscaling. The new images are based on Ubuntu 24.04 LTS, replacing the previous 22.04 LTS version.
Upgrades will also be faster, as nodes will be replaced instead of rebooted.
Learn how to profit of this new system and more https://www.scaleway.com/en/docs/kubernetes/how-to/upgrade-kapsule-new-node-image-system/
Forced migration on the new system will be scheduled by region
The migration will be rolled out across the following regions during the specified weeks:
WAW Region: Starting December 1st (Week 49)
AMS Region: Starting December 2nd (Week 49)
PAR Region: Between December 8th and December 11th (Week 50)
While being automatically migrated, your cluster will remain up and running. You might experience a brief service interruption if your cluster has only one node. As long as you have multiple nodes, the migration will be completely transparent.
If no action is taken by the start date of your region's migration window, your clusters will be automatically migrated by our system to ensure you benefit from the new features and maintain compliance with our product roadmap.
If you have any questions or require assistance, please contact our support team.
Posted on Nov 05, 2025 - 10:44 CET
The advantages of the new image system include improved boot time, reduced from over five minutes to under one minute, and faster autoscaling. The new images are based on Ubuntu 24.04 LTS, replacing the previous 22.04 LTS version.
Upgrades will also be faster, as nodes will be replaced instead of rebooted.
Learn how to profit of this new system and more https://www.scaleway.com/en/docs/kubernetes/how-to/upgrade-kapsule-new-node-image-system/
Forced migration on the new system will be scheduled by region
The migration will be rolled out across the following regions during the specified weeks:
WAW Region: Starting December 1st (Week 49)
AMS Region: Starting December 2nd (Week 49)
PAR Region: Between December 8th and December 11th (Week 50)
While being automatically migrated, your cluster will remain up and running. You might experience a brief service interruption if your cluster has only one node. As long as you have multiple nodes, the migration will be completely transparent.
If no action is taken by the start date of your region's migration window, your clusters will be automatically migrated by our system to ensure you benefit from the new features and maintain compliance with our product roadmap.
If you have any questions or require assistance, please contact our support team.
Posted on Nov 05, 2025 - 10:44 CET
[DC2][RPN] - RPN Switch Isolation Room 103 Rack F09 Dec 3, 2025 08:00-09:00 CET
Due to new network flaps seen on RPN switch located on Room 103 Rack F09, we'll proceed with the change of port on the router on which is connected the switch.
Customer should expect RPN traffic impact the time of the intervention (should be around 30 minutes maximum)
Traffic to the internet is not impacted
Posted on Nov 28, 2025 - 18:11 CET
Customer should expect RPN traffic impact the time of the intervention (should be around 30 minutes maximum)
Traffic to the internet is not impacted
Posted on Nov 28, 2025 - 18:11 CET
[MANAGED-REDIS] Scheduled maintenance for Managed Database for Redis™ Instances in AMS & WAW regions Dec 9, 2025 09:00-13:00 CET
We would like to inform you that a scheduled maintenance will take place on your Managed Database for Redis™ instance(s) located in AMS & WAW regions.
Maintenance details: Upgrade of the underlying infrastructure to improve reliability and security.
Maintenance window: 9 Dec. 2025, 9:00 AM – 1:00 PM (CET)
Impact duration: Up to 1 minute of downtime within the maintenance window
What to expect:
A brief restart (~1 minute) for standalone instances
A primary node switchover for high availability instances and clusters (no significant downtime expected)
This operation is part of our continuous effort to maintain and enhance the quality and stability of your service. We appreciate your understanding and cooperation
Posted on Nov 26, 2025 - 14:18 CET
Maintenance details: Upgrade of the underlying infrastructure to improve reliability and security.
Maintenance window: 9 Dec. 2025, 9:00 AM – 1:00 PM (CET)
Impact duration: Up to 1 minute of downtime within the maintenance window
What to expect:
A brief restart (~1 minute) for standalone instances
A primary node switchover for high availability instances and clusters (no significant downtime expected)
This operation is part of our continuous effort to maintain and enhance the quality and stability of your service. We appreciate your understanding and cooperation
Posted on Nov 26, 2025 - 14:18 CET
[MANAGED-REDIS] Scheduled maintenance for Managed Database for Redis™ Instances in in fr-par-2 Dec 9, 2025 14:00-18:00 CET
We would like to inform you that a scheduled maintenance will take place on your Managed Database for Redis™ instance(s) located in fr-par-2.
Maintenance details: Upgrade of the underlying infrastructure to improve reliability and security.
Maintenance window: 9 Dec. 2025, 2:00 PM – 6:00 PM (CET)
Impact duration: Up to 1 minute of downtime within the maintenance window
What to expect:
A brief restart (~1 minute) for standalone instances
A primary node switchover for high availability instances and clusters (no significant downtime expected)
This operation is part of our continuous effort to maintain and enhance the quality and stability of your service. We appreciate your understanding and cooperation.
Posted on Nov 26, 2025 - 14:20 CET
Maintenance details: Upgrade of the underlying infrastructure to improve reliability and security.
Maintenance window: 9 Dec. 2025, 2:00 PM – 6:00 PM (CET)
Impact duration: Up to 1 minute of downtime within the maintenance window
What to expect:
A brief restart (~1 minute) for standalone instances
A primary node switchover for high availability instances and clusters (no significant downtime expected)
This operation is part of our continuous effort to maintain and enhance the quality and stability of your service. We appreciate your understanding and cooperation.
Posted on Nov 26, 2025 - 14:20 CET
[MANAGED-REDIS] Scheduled maintenance impacting your Managed Database for Redis™ Instances in fr-par-1 Dec 10, 2025 09:00-13:00 CET
We would like to inform you that a scheduled maintenance will take place on your Managed Database for Redis™ instance(s) located in fr-par-1.
Maintenance details: Upgrade of the underlying infrastructure to improve reliability and security.
Maintenance window: 10 Dec. 2025, 9:00 AM – 6:00 PM (CET)
Impact duration: Up to 1 minute of downtime within the maintenance window
What to expect:
A brief restart (~1 minute) for standalone instances
A primary node switchover for high availability instances and clusters (no significant downtime expected)
This operation is part of our continuous effort to maintain and enhance the quality and stability of your service. We appreciate your understanding and cooperation.
Posted on Nov 26, 2025 - 14:22 CET
Maintenance details: Upgrade of the underlying infrastructure to improve reliability and security.
Maintenance window: 10 Dec. 2025, 9:00 AM – 6:00 PM (CET)
Impact duration: Up to 1 minute of downtime within the maintenance window
What to expect:
A brief restart (~1 minute) for standalone instances
A primary node switchover for high availability instances and clusters (no significant downtime expected)
This operation is part of our continuous effort to maintain and enhance the quality and stability of your service. We appreciate your understanding and cooperation.
Posted on Nov 26, 2025 - 14:22 CET