Scaleway Outage History

Started Jun 09, 2026, 08:30 AM UTC· resolved Jun 09, 2026, 03:21 PM UTC

1. investigating Jun 09, 2026, 08:30 AM UTC

   Customers may experience connectivity issues on MongoDB public endpoints due to a flap on an internal component.

2. resolved Jun 09, 2026, 03:21 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 08, 2026, 04:08 PM UTC· resolved Jun 09, 2026, 07:35 AM UTC

1. identified Jun 08, 2026, 04:08 PM UTC

   Customers may experience network congestion between Paris and Amsterdam due to a partial loss of redundancy on the RPN network.

2. identified Jun 08, 2026, 04:11 PM UTC

   We are continuing to work on a fix for this issue.

3. resolved Jun 09, 2026, 07:35 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 08, 2026, 02:22 PM UTC· resolved Jun 08, 2026, 02:22 PM UTC

1. resolved Jun 08, 2026, 02:22 PM UTC

   Customers may experience connectivity issues in the it-mil-1 zone due to a DHCP service disruption.

Read the full incident report →

Started Jun 05, 2026, 03:26 PM UTC· resolved Jun 08, 2026, 02:14 PM UTC

1. investigating Jun 05, 2026, 03:26 PM UTC

   Customers may experience instabilities when using the model qwen3.5-397b-a17b.

2. resolved Jun 08, 2026, 02:14 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 05, 2026, 09:22 AM UTC· resolved Jun 08, 2026, 12:53 PM UTC

1. investigating Jun 05, 2026, 09:22 AM UTC

   Customers may experience high latencies on Block Storage volumes in fr-par-1 due to increased background operations on the underlying storage system.

2. monitoring Jun 05, 2026, 02:50 PM UTC

   Customers may experience high latencies on Block Storage volumes in fr-par-1 due to increased background operations on the underlying storage system. The issue has been identified and mitigated. We are monitoring the situation to ensure a full recovery.

3. resolved Jun 08, 2026, 12:53 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 04, 2026, 10:55 AM UTC· resolved Jun 04, 2026, 12:16 PM UTC

1. investigating Jun 04, 2026, 10:55 AM UTC

   Customers may experience installation failures when attempting to install Rocky Linux 9 on Dedibox dedicated servers due to an error in the storage module.

2. resolved Jun 04, 2026, 12:16 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 03, 2026, 10:20 AM UTC· resolved Jun 03, 2026, 12:28 PM UTC

1. investigating Jun 03, 2026, 10:20 AM UTC

   We will be performing an urgent maintenance on one of our core routers located in Marseille Interxion 2 Routers. The maintenance will take place 04/06/2026 between 12:00 to 13:00 CET time Downtime expected to 15 minutes Interlink Traffic going through Interxion MRS2 will be temporarily stopped due to Interlink-Router being unavailable the time of the maintenance. We'll stop sending & advertising routes between the AZs and the Interlink Routers. BGP Sessions with customers will still be up. Public traffic that are going through this PoP will not impacted has it will be redirected towards other PoPs connected to the Internet. However, despite this offload and redundancy, some temporary side effects may occur during the maintenance window, including: - Brief connectivity interruptions - Temporary increases in latency - Packet loss - Routing changes - Network reconvergence These impacts may affect services hosted in Paris and, due to interconnections between sites, could also potentially impact Amsterdam. We are taking all necessary measures to minimize disruption and ensure a swift return to normal operations.

Read the full incident report →

Started Jun 02, 2026, 01:05 PM UTC· resolved Jun 05, 2026, 09:20 AM UTC

1. investigating Jun 02, 2026, 01:05 PM UTC

   Customers may experience slow operations or timeouts when using the Container Registry in the fr-par region.

2. investigating Jun 02, 2026, 01:10 PM UTC

   We are continuing to investigate this issue.

3. resolved Jun 05, 2026, 09:20 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 02, 2026, 08:57 AM UTC· resolved Jun 05, 2026, 02:21 PM UTC

1. investigating Jun 02, 2026, 08:57 AM UTC

   We have noticed that payments with AMEX card are not successful. Our engineers are investigating.

2. identified Jun 04, 2026, 10:03 AM UTC

   To date, we have had about fifty payment errors involving AMEX cards. This follows a recent change on our end to comply with geopolitical restrictions (particularly regarding Russia) on the PayPlug side. It turns out that IPv6 addresses are not compatible with PayPlug / Dalenys and our AMEX cards. We’ve taken the necessary steps to set up “block reminders,” so customers won’t be locked out or have their services suspended. We’ll try to resolve the issue and implement a fundamental fix ASAP; we’re meeting with the team today.

3. monitoring Jun 05, 2026, 12:24 PM UTC

   The incident is now mitigated, and we are actively monitoring the situation. Failed AMEX payments have been retried and are processing successfully. New orders and renewals can now be processed using AMEX as normal.

4. resolved Jun 05, 2026, 02:21 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 01, 2026, 08:05 AM UTC· resolved Jun 01, 2026, 08:20 AM UTC

1. investigating Jun 01, 2026, 08:05 AM UTC

   Customers may experience slow response times or connection errors when accessing Grafana.

2. resolved Jun 01, 2026, 08:20 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 29, 2026, 01:20 PM UTC· resolved May 29, 2026, 01:34 PM UTC

1. monitoring May 29, 2026, 01:20 PM UTC

   Customers may experience performance issues and errors when using the mistral-small-3.2-24b-instruct-2506 model due to a load increase on an internal component.

Read the full incident report →

Started May 29, 2026, 01:18 PM UTC· resolved May 29, 2026, 04:11 PM UTC

1. monitoring May 29, 2026, 01:18 PM UTC

   Customers may experience performance issues and errors when using the gemma-4-26b-a4b-it model due to a load increase on an internal component.

2. resolved May 29, 2026, 04:11 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 28, 2026, 06:15 PM UTC· resolved May 28, 2026, 08:05 PM UTC

1. investigating May 28, 2026, 06:15 PM UTC

   We have received reports of a 500 error occurring when creating or opening a ticket, making these actions impossible.

2. resolved May 28, 2026, 08:05 PM UTC

   The issue has been resolved We apologise for any inconvenience caused

Read the full incident report →

Started May 28, 2026, 04:08 PM UTC· resolved May 29, 2026, 09:05 AM UTC

1. investigating May 28, 2026, 04:08 PM UTC

   We are investigating performance degradation affecting Block Storage volumes in fr-par-3. Connectivity issues may result in intermittent request failures.

2. resolved May 29, 2026, 09:05 AM UTC

   Some ongoing work on a construction site above the datacenter has impacted the cooling system, we have seen a rise of temperature triggering some hardware safety measure. Temperature is now under control, our datacenter provider is monitoring closely the situation and ready to deploy fallback solution if needed. Due to the hardware safety measure you may have seen impact on your read/write operation between 17:35 UTC+2 to 18:14 UTC+2 May 28th.

Read the full incident report →

Started May 28, 2026, 12:41 PM UTC· resolved May 29, 2026, 07:33 AM UTC

1. investigating May 28, 2026, 12:41 PM UTC

   Customers may experience instabilities when using Serverless Containers in the fr-par region.

2. monitoring May 28, 2026, 01:42 PM UTC

   Everything has returned to normal for the impacted containers. We are continuing to monitor the situation to ensure everything is fine.

3. investigating May 28, 2026, 03:36 PM UTC

   We are experiencing instability again. We are investigating.

4. monitoring May 28, 2026, 04:21 PM UTC

   Everything has returned to normal for the impacted services. We'll let the status in monitoring for the night to ensure everything is fine.

5. resolved May 29, 2026, 07:33 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 28, 2026, 10:25 AM UTC· resolved May 29, 2026, 06:59 AM UTC

1. investigating May 28, 2026, 10:25 AM UTC

   Customers may experience issues creating new data warehouses in fr-par-1 due to a partial outage on an internal component. Our engineers are currently working on the situation.

2. resolved May 29, 2026, 06:59 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 27, 2026, 05:57 PM UTC· resolved May 28, 2026, 03:26 PM UTC

1. investigating May 27, 2026, 05:57 PM UTC

   Customers are unable to disable their Alertmanager configuration in Cockpit.

2. resolved May 28, 2026, 03:26 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 27, 2026, 02:57 PM UTC· resolved May 28, 2026, 06:35 AM UTC

1. investigating May 27, 2026, 02:57 PM UTC

   Customers may experience unavailability of the Instances API in the it-mil-1 region due to an internal dependency issue.

2. investigating May 27, 2026, 03:16 PM UTC

   We are continuing to investigate this issue.

3. investigating May 27, 2026, 03:21 PM UTC

   We are continuing to investigate this issue.

4. monitoring May 27, 2026, 06:23 PM UTC

   A fix has been implemented and we are monitoring the results.

5. resolved May 28, 2026, 06:35 AM UTC

   The issue root cause has been identified and corrected, we are monitoring the service status.

Read the full incident report →

Started May 26, 2026, 01:28 PM UTC· resolved Jun 08, 2026, 11:49 AM UTC

1. investigating May 26, 2026, 01:28 PM UTC

   Since Friday, after the DC5 operator room electrical incident. EM-RV1 seems to be stuck in a boot loop, unable to boot successfully from the network. In the meantime, do not reboot your system Also, you will not be able to create new EM-RV1 server and booting them

2. monitoring Jun 08, 2026, 11:45 AM UTC

   The issue has been fixed. Servers are no longer stuck in a boot loop state. We are still monitoring the situation and ensuring that our fix will work long‑term.

3. resolved Jun 08, 2026, 11:49 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 26, 2026, 10:59 AM UTC· resolved May 28, 2026, 10:26 AM UTC

1. investigating May 26, 2026, 10:59 AM UTC

   Customers may experience instability on one of our six Serverless Containers clusters in the fr-par region.

2. monitoring May 26, 2026, 12:28 PM UTC

   Everything has returned to normal for the impacted cluster. We are continuing to monitor the situation to ensure everything is fine.

3. resolved May 28, 2026, 10:26 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 26, 2026, 09:47 AM UTC· resolved May 29, 2026, 12:09 PM UTC

1. investigating May 26, 2026, 09:47 AM UTC

   Customers may experience connectivity issues with the Data Warehouse API in the fr-par region due to an internal dependency.

2. resolved May 29, 2026, 12:09 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 25, 2026, 10:03 AM UTC· resolved May 25, 2026, 12:25 PM UTC

1. investigating May 25, 2026, 10:03 AM UTC

   Customers may experience latencies on query and ingestion of external logs in the fr-par region due to an internal dependency issue.

2. resolved May 25, 2026, 12:25 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 25, 2026, 08:28 AM UTC· resolved May 25, 2026, 09:37 AM UTC

1. investigating May 25, 2026, 08:28 AM UTC

   Customers are unable to create new SQS/NATS triggers for Serverless Functions in the fr-par region. Serverless Containers are unaffected.

2. resolved May 25, 2026, 09:37 AM UTC

   From Friday 22/05 13:30 CET to Monday 25/05 11:00 CET, creation of messaging triggers for Serverless Functions was unavailable. Existing triggers still worked as expected, but may have been wrongfully marked in the `error` status by an automatic process. Situation is back to nominal state and messaging trigger creation should no longer fail. We apologize for the disruption.

Read the full incident report →

Started May 25, 2026, 08:05 AM UTC· resolved May 25, 2026, 08:05 AM UTC

1. resolved May 25, 2026, 08:05 AM UTC

   Traces ingestion and query were partially impacted on the fr-par AZ since 23/05/2026 10h45 CEST. We have since resolved the incident and are currently monitoring its progress.

Read the full incident report →

Started May 22, 2026, 09:21 AM UTC· resolved May 23, 2026, 12:40 PM UTC

1. investigating May 22, 2026, 09:21 AM UTC

   We are currently investigating on that issue right now.

2. investigating May 22, 2026, 09:21 AM UTC

   We are continuing to investigate this issue.

3. investigating May 22, 2026, 09:23 AM UTC

   We are continuing to investigate this issue.

4. monitoring May 22, 2026, 09:42 AM UTC

   Most services recovered and our teams are mobilized to recover the rest. Root cause is a power issue in datacenter.

5. monitoring May 22, 2026, 10:24 AM UTC

   Datacenter hosting FR-PAR-2 availability zone occured a complete power failure in operator rooms during a planned datacenter maintenance. Both operator rooms (network connectivity) were powerless for a few minutes leading to a complete isolation of the availability zone during the issue. We are investigating with the datacenter provider to understand the root cause.”

6. monitoring May 22, 2026, 10:28 AM UTC

   Teams are working on the recovery. Here is the status of impacted products: - Instances: you may encounter issues with l_ssd/block snapshots or volumes - Kapsule: Control planes are reachable and in nominal state, you may need to verify that your controllers reconnected properly on the apiservers. You may have experienced node replacement due to the autoheal or autoscaling process, this may delay volume re-attachments. - Databases: snapshots may be blocked, some failovers have been started for HA - Object storage: you may encounter some latencies

7. identified May 22, 2026, 10:31 AM UTC

   Datacenter informs us that we are running on power generators for now until the root cause is identified

8. identified May 22, 2026, 10:44 AM UTC

   As the power failure root cause is not yet understood (datacenter is investigating with its providers), we encourage you to shift workload on alternatives regions/AZ if possible.

9. monitoring May 22, 2026, 11:10 AM UTC

   Updated status for impacted products: - Instances: everything back to normal - Kapsule: same status - Databases: same status - Object Storage: same status - Serveless containers and functions: might face connection timeout issues when contacting their applications

10. monitoring May 22, 2026, 11:25 AM UTC

    Clarification: only network rooms are running on power generators, with enough fuel for a few days

11. monitoring May 22, 2026, 12:26 PM UTC

    Updated status for impacted products: - Kapsule: everything back to normal - Databases: everything back to normal - Object Storage: still some latency issues and timeout on connecting some buckets - Serveless containers and functions: might face connection timeout issues when contacting their applications - File Storage: some instances may encounter troubles with their File Storage, we invite customers to restart their instances/nodes if affected

12. monitoring May 22, 2026, 02:30 PM UTC

    Updated status for impacted products: - Object Storage: still some latency issues and timeout on connecting some buckets - Serveless containers and functions: Everything is back to normal. Situation recovered and stable since 02:40 PM - File Storage: some instances may encounter troubles with their File Storage, we invite customers to restart their instances/nodes if affected

13. monitoring May 22, 2026, 02:57 PM UTC

    Updated status for impacted products: - Object Storage: Everything back to normal - Serveless containers and functions: Everything is back to normal. - File: some instances may encounter troubles with their File Storage, we invite customers to restart their instances/nodes if affected As the failover malfunction has not been diagnosed at this time, our datacenter manager will keep the affected elements under a generator.

14. monitoring May 22, 2026, 08:30 PM UTC

    The datacenter provider has planned an intervention on Saturday at 10:30 CEST to replace batteries on the electrical paths that had issues today. This operation will be done live and should have no impact. Once replaced, old batteries will be inspected and tested to confirm they were the cause of the incident. Power will be kept on generators during this operation and after until the root cause is fully confirmed

15. monitoring May 23, 2026, 09:56 AM UTC

    Batteries replacement is ongoing, 1 of the 4 electrical paths has been done (no impact). Datacenter teams will proceed with the next paths.

16. monitoring May 23, 2026, 11:09 AM UTC

    Batteries replacement has been completed on all 4 electrical paths. Removed batteries are under tests and investigations to confirm their involvement in the initial incident. No more action on production expected for now. We are still on power generators for the time being.

17. monitoring May 23, 2026, 11:41 AM UTC

    Datacenter teams are now confident the batteries were involved in the initial incident, they will attempt to switch back to main power at 14:30 CEST.

18. resolved May 23, 2026, 12:40 PM UTC

    Switchover to main power has been completed successfully. We are back to a nominal state.

19. postmortem Jun 05, 2026, 03:32 PM UTC

    **Correction to Error Report dated June 3, 2026** **FR PAR 2 Connectivity Loss** **Incident Overview** On 22 May 2026, power maintenance in the OpCore PAR5 datacenter led to a total loss of power in the 2 operator rooms. This shutdown caused a global connectivity loss for the FR-PAR-2 availability zone from 11:08 to 11:10 UTC\+2. Service restoration continued until 12:30 UTC\+2. **Incident status links:** [https://status.scaleway.com/incidents/qkj49g6g3ykp](https://status.scaleway.com/incidents/qkj49g6g3ykp) **Regions/AZ Impacted**: FR-PAR-2 **Initial Duration**: 1h50 **Duration by impacted products** : * **Control-Plane:** mainly 20 minutes. * **Data-Plane:** mainly 20 minutes, though some effects continued after connectivity was restored. * **Instance:** 1h50 for instances with block volumes. * **Kapsule:** 1h50, but actions were required on the customer side. \(please check on your end for faulty sockets or connections on your controller or workload. For example, broken SFS sockets\). * **Database:** 1h50, to verify that all databases had returned to a healthy state. * **Object Storage:** TBD \(pending investigation\). Latencies persisted after connectivity was restored. * **File Storage:** 1h50, but actions were required on the customer side. * **Serverless Containers and Functions:** 3h30, due to a Cilium bug affecting recovery after the incident * **Dedibox / Elastic Meta**l: 20 minutes **Primary Impact**: Connectivity Loss **Secondary Impact**: Products with a presence in FR-PAR-2. Mainly Instance, Kapsule, Databases, Object Storage, File Storage, and Serverless Containers & Functions. #### **Impact on Customers** During the incident, all services hosted in FR-PAR-2 were unreachable #### **Root Cause Analysis** **5 whys** * **Why did all networks go down in FR-PAR-2 ?** The datacenter hosting FR-PAR-2 is connected to the backbone through two distinct network paths and equipment, hosted in two distinct rooms in the datacenter. Each of these rooms is powered by two electrical paths. Each electrical path hosts an electrical workshop that converts power \(230 V / 48 V\) to feed the equipment in the room. For a reason that is still unknown, all two electrical workshops encountered an issue triggering network equipment reboot. * **Why did power have an issue ?** Maintenance was planned by the datacenter operator to test the power generators. This is a recurring test, carried out every few weeks to ensure the power generators, batteries, and power switching systems are working correctly. Rectifier batteries failed to support load during switch phase from main to generators leading to 10 seconds power loss. * **Why were software services affected by the power/network issue?** When the availability zone became disconnected from the other AZs, it caused a disconnection of redundant systems \(failover, DBs, data synchronisation, etc.\). When the AZ reconnected, we needed to unlock DBs, reconnect master/slaves, and resync data from the other AZs, which caused some delay in fully restoring services. In addition, many customer requests \(automated or not\) were queued and had to be processed in order to ensure the system remained consistent, causing increased latencies and delays. * **Why were other Availability Zones affected ?** Other availability zones in FR-PAR were partially impacted during the disconnection event. This was mostly caused by failover systems handling the large surge of requests needed to fail over every redundant part of each software service, causing delays and latencies in processing everything. **Conclusion** We will continue to analyse the various events that slowed down some failover events with the other AZs. A series of batteries were confirmed as faulty and have been replaced in the following 24 hours by the provider. The batteries were guaranteed for 12 years and were only at 8 years of service. Investigation is ongoing with the battery provider to understand the underlying cause of early faults. #### **RemediationShort term** **Datacenter provider:** * Battery have been replaced **Mid term** **Scaleway:** * Working on improving our recovery process. **Datacenter provider:** * Pending investigation. **Contact** If you have any further questions or need assistance, please contact our support team. **Impacted services state.** | Service | Mono AZ impact duration | Multi AZ impact duration | Comments | | --- | --- | --- | --- | | Instance | 1 hour and 50 minutes | N/A | Instances on FR-PAR-2 impacted. | | Block storage | 1 hour and 50 minutes | N/A | Availability for some elements stored in FR-PAR-2 \(20 minutes\)After power restarted, some latencies \(10 minutes\) | | Kapsule \(K8S\) | 1 hour and 50 minutes | 10 minutes | Time to converge and respawn assets. | | Object storage | 1 hour and 50 minutes | 0 minutes | Multi AZ not impacted One zone object storage: if the bucket is on FR-PAR-2, this one was unavailable. | | Managed Databases | 1 hour and 50 minutes \(only multi AZ replica impacted\) | N/A | It was not possible to create a multi AZ HA database, or to connect/promote a read replica. | | [api.scaleway.com](http://api.scaleway.com) | N/A | 0 minutes | api is regional no outage. | | [console.scaleway.com](http://console.scaleway.com) | N/A | 1 hour and 50 minutes | failover not working as expected. | | file storage | 1 hour and 50 minutes | N/A | manual intervention was required from customers to recover. | | Serverless Container and Functions | 3 hours and 30 minutes | | Network problems on recovery led to an extended outage. |

Read the full incident report →