THIS IS A SCHEDULED EVENT Jun <var data-var='date'>1</var>, <var data-var='time'>10:00</var> - <var data-var='time'>12:00</var> UTC May <var data-var='date'>11</var>, <var data-var='time'>16:24</var> UTC Scheduled - Starting May 31, 2026, MongoDB Playground clusters will be automatically and permanently deleted 30 days after their creation date, as outlined in our customer documentation. https://docs.ionos.com/cloud/databases/mongodb/overview What is changing * Existing clusters created more than 30 days before May 31, 2026 will be deleted on May 31, 2026. * Existing clusters created less than 30 days before May 31, 2026 will be deleted 30 days after their creation date. * New clusters created on or after May 31, 2026 will be deleted 30 days after creation. Playground clusters do not include automated backups, so any data not exported before deletion will be unrecoverable. Action required * If you want to keep your data, please export it before your cluster's deletion date using mongodump. See MongoDB Backup & Recovery. * Need your cluster for longer than 30 days? MongoDB Business Edition removes the 30-day limit and adds automated daily backups, higher connection limits, and production-ready performance. * MongoDB Documentation: https://docs.ionos.com/cloud/databases/mongodb * MongoDB Backup & recovery overview: https://docs.ionos.com/cloud/databases/mongodb/overview/backup-and-recovery Affected services: Database as a Service (DBaaS) Location: Global Services

MongoDB Playground: 30-day cluster lifecycle policy takes effect

THIS IS A SCHEDULED EVENT May <var data-var='date'>27</var>, <var data-var='time'>15:00</var> - <var data-var='time'>16:00</var> UTC May <var data-var='date'>13</var>, <var data-var='time'>10:19</var> UTC Scheduled - UPDATE: Maintenance start moved from 16:30 UTC to 15:00 UTC) On Wednesday, 27 May 2026, between 17:00 and 18:00 CEST (15:00–16:00 UTC), we will perform scheduled maintenance to move our sign-in platform to upgraded, geo-redundant infrastructure. During this window, signing in to the Cloud Console (DCD), Reseller Portal, Partner Portal, Partner Applications, CRM, and single sign-on (SSO) flows may be briefly interrupted, and some users may need to sign in again after the maintenance. Already-authenticated API traffic and existing automations are not affected. No password change or account action is required. We have prepared and tested this change carefully and apologize for any inconvenience this short interruption may cause. Affected services: Data Center Designer (DCD) Location: APIs and Frontends

IAM Cluster Migration

THIS IS A SCHEDULED EVENT May <var data-var='date'>27</var>, <var data-var='time'>05:00</var> - <var data-var='time'>06:30</var> UTC May <var data-var='date'>22</var>, <var data-var='time'>22:45</var> UTC Scheduled - We would like to inform you that regular maintenance of the Cloud Panel is due to be carried out. During this time, access to the Cloud Panel will be limited while access to the vSphere Clients, NSX Managers and the management VPN themselves will not be impacted. Availability and accessibility of your Private Cloud resources will remain unaffected.

Cloud Panel Maintenance

May <var data-var='date'>21</var>, <var data-var='time'>20:00</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'>21</var>, <var data-var='time'>16:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. May <var data-var='date'>19</var>, <var data-var='time'>17:15</var> UTC Scheduled - As part of our ongoing platform improvements, we will be performing an infrastructure upgrade to enhance the reliability, security, and performance of the Monitoring and Logging services in the listed regions. Customer impact: A short interruption to ingestion endpoints for Monitoring and Logging may occur during the maintenance window. Previously ingested data is retained and remains accessible after the maintenance completes. No customer action is required. Affected services: Logging Service Location: Location DE/FRA, Location DE/TXL, Location FR/PAR, Location GB/LHR

Planned infrastructure upgrade — Monitoring & Logging Services (PAR, LHR, FRA, TXL)

May <var data-var='date'>20</var>, <var data-var='time'>21:38</var> UTC Resolved - We consider this incident as resolved. An RCA will follow as soon as it's compiled. May <var data-var='date'>20</var>, <var data-var='time'>14:41</var> UTC Monitoring - The team was able to resolve the issue and bring all instances back online, so the network and connectivity is back now. We keep monitoring the situation for stability. May <var data-var='date'>20</var>, <var data-var='time'>13:42</var> UTC Identified - The team identified the root cause and is working on a fix now. We need to migrate several VMs to get them back online. We will keep you informed on any change. May <var data-var='date'>20</var>, <var data-var='time'>12:19</var> UTC Investigating - We are currently facing a network issue in Worcester. Several customer NICs are down due to the outage, so connectivity is lost for the affected instances. Our team is currently working on re-establishing connectivity as soon as possible. We will keep you informed on any new information. Affected services: Network Location: Location GB/BHX

Network Outage in Worcester

May <var data-var='date'>20</var>, <var data-var='time'>06:30</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'>20</var>, <var data-var='time'>05:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. May <var data-var='date'>15</var>, <var data-var='time'>16:02</var> UTC Scheduled - We would like to inform you that regular maintenance of the Cloud Panel is due to be carried out. During this time, access to the Cloud Panel will be limited while access to the vSphere Clients, NSX Managers and the management VPN themselves will not be impacted. Availability and accessibility of your Private Cloud resources will remain unaffected.

May <var data-var='date'>19</var>, <var data-var='time'>19:00</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'>19</var>, <var data-var='time'>14:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. May <var data-var='date'>13</var>, <var data-var='time'>16:04</var> UTC Scheduled - As part of our ongoing platform improvements, we will be performing an infrastructure upgrade to enhance the reliability, security, and performance of the Monitoring and Logging services in the listed regions. Customer impact: A short interruption to ingestion endpoints for Monitoring and Logging may occur during the maintenance window. Previously ingested data is retained and remains accessible after the maintenance completes. No customer action is required. Affected services: Logging Service Location: Location ES/VIT, Location GB/BHX, Location US/EWR, Location US/LAS, Location US/MCI

Planned infrastructure upgrade — Monitoring & Logging Services (MCI, LAS, EWR, BHX, VIT)

May <var data-var='date'>19</var>, <var data-var='time'>16:24</var> UTC Resolved - We are marking this incident as resolved. The root cause of the service degradation affecting Kubernetes Control Planes in FRA has been identified as a DDoS attack targeting customers hosted on our infrastructure. This incident has been documented here: https://status.ionos.cloud/incidents/kknrz6284jl0 The identified bottleneck led to the observed intermittent reachability issues and increased latency between Kubernetes etcd nodes for the affected customers. May <var data-var='date'>15</var>, <var data-var='time'>13:35</var> UTC Monitoring - A fix has been implemented and we are monitoring the results. May <var data-var='date'>15</var>, <var data-var='time'>12:18</var> UTC Identified - We are currently investigating service degradation for Control Planes of some Kubernetes clusters in the Frankfurt region (de/fra). This could impact K8s workload changes for several customers. Our teams are working on a fix.

Partial Connectivity Degradation to Control Plane Affecting Kubernetes Operations in Frankfurt (de/fra)

May <var data-var='date'>19</var>, <var data-var='time'>16:17</var> UTC Resolved - We are marking this incident as resolved. The Root Cause of the incident was a DDOS attack on customers hosted in our infrastructure. While the attack was largely successfully mitigated by our countermeasures a intermittent saturation of an affected link resulted in an increase of package loss. Our network team has evaluated the countermeasures' effectiveness and the identified bottleneck and is currently working on technical and organizational improvements to further decrease detection time for comparable events. May <var data-var='date'>15</var>, <var data-var='time'>13:18</var> UTC Monitoring - A fix has been implemented and we are monitoring the results. May <var data-var='date'>15</var>, <var data-var='time'>11:59</var> UTC Investigating - We are writing to inform you that we have been experiencing sporadic connection issues and substantial delays on packet delivery. Network technicians have started working on the occurrence immediately after detection and will isolate the problem and solve the issue as quick as possible. However, it is possible that there will be a certain degradation in connection quality affecting individual virtual resources. We will inform you as soon as the functionality has been restored.

Network packet loss

May <var data-var='date'>18</var>, <var data-var='time'>07:38</var> UTC Resolved - As redundancy has been fully restored, we are resolving this incident. A RCA is being prepared and we estimate that it will be shared here today or tomorrow. May <var data-var='date'>12</var>, <var data-var='time'>23:06</var> UTC Monitoring - Our team has recovered the remaining VMs. It’s important to note that storage redundancy is not yet fully restored. Due to necessary data synchronization processes and the volume of data involved, full recovery will take several additional hours. Important notice for affected customers: - Load: To ensure stability of the recovered VMs, please try to avoid excessive storage load where possible. - Provisioning: Provisioning jobs against affected VMs will not be possible until redundancy is fully restored. Consequently, making state changes will not be possible during this time. - VM States: During the incident, the state of affected VMs may have changed; some may currently be in "shutoff" state. - Manual Intervention: To avoid unintended impact on customers for whom "shutoff" is the desired state, we cannot automatically restart all VMs without approval. Due to these constraints, we kindly ask affected customers to carefully check their resources and request state changes via support ticket (support@cloud.ionos.com) where necessary. This is only needed until redundancy is restored. We are moving this incident to Monitoring status while work to restore full redundancy continues. We will provide an update here once that work is complete. A detailed Root Cause Analysis (RCA) will be published subsequently, explaining the cause of the incident, the measures taken to restore service, and the steps implemented to prevent recurrence. We thank our customers and partners for their patience and cooperation in ensuring the full recovery of affected services and workloads. May <var data-var='date'>12</var>, <var data-var='time'>21:08</var> UTC Update - We have successfully recovered additional VMs. However, because full storage redundancy has not yet been reached for these systems, Storage Provisioning Jobs will currently fail. We ask affected customers to refrain from making configuration changes or placing excessive load on these servers until redundancy is fully restored. May <var data-var='date'>12</var>, <var data-var='time'>20:12</var> UTC Update - The team has succeeded in restoring the first VMs during the initial run. We are currently working on rolling out the restoration process further and will update on the progress. May <var data-var='date'>12</var>, <var data-var='time'>20:00</var> UTC Update - Our development team is working on re-establishing connectivity sessions of the affected VMs so that the recovery effort can continue. The first runs are currently starting. May <var data-var='date'>12</var>, <var data-var='time'>19:23</var> UTC Update - The team has encountered a blocker while restarting the remaining VMs due to connectivity issues between the replaced hosts and the storage servers. This has significantly increased the complexity of the recovery effort. We are currently collaborating with a specialized development team to bring the remaining systems back online. We will provide the next update at 20:00 UTC or before if there are meaningful updates. May <var data-var='date'>12</var>, <var data-var='time'>16:01</var> UTC Update - We have made progress regarding the recovery, and are currently in the process of restarting affected Virtual Machines. May <var data-var='date'>12</var>, <var data-var='time'>13:53</var> UTC Update - The spares have been made available. They are currently brought online to allow recovery to continue. We estimate that we will have another update on the progress within the hour. May <var data-var='date'>12</var>, <var data-var='time'>12:49</var> UTC Update - We found relevant hardware to be defective, this has to be replaced first in the data center. After the physical connection is back, we need to sync and update the storage servers to get the VMs back online. We are working as fast as we can to get this fixed, however, this might take some hours. May <var data-var='date'>12</var>, <var data-var='time'>11:23</var> UTC Identified - Our storage team is currently working on a firmware restore and upgrade on the affected storage servers and will then attempt to bring them back into service. May <var data-var='date'>12</var>, <var data-var='time'>11:04</var> UTC Investigating - Unfortunately, we ran into further issues with our Storages in Karlsruhe, so the team keeps on repairing. Affected VMs (and VDCs) are not available and have to be restarted once they get back online. We will keep you updated asap on any new information. May <var data-var='date'>12</var>, <var data-var='time'>08:59</var> UTC Monitoring - All VMs and Storages and VDCs are back online and available. We keep monitoring the situation. May <var data-var='date'>12</var>, <var data-var='time'>08:02</var> UTC Identified - Our developers restored the storage availability, we are now restarting the affected VMs to bring them back online. May <var data-var='date'>12</var>, <var data-var='time'>06:15</var> UTC Investigating - We are currently experiencing restrictions regarding our Storage service in one cluster in our Karlsruhe region. We are working to restore regularly operation of our services as quickly as possible.

Availability of storage service partially limited in Karlsruhe

May <var data-var='date'>18</var>, <var data-var='time'>07:36</var> UTC Resolved - Redundancy has been fully restored and no limitations related to provisioning should remain. May <var data-var='date'>13</var>, <var data-var='time'>15:33</var> UTC Identified - As documented in the updates to the recent Storage Incident in our Karlsruhe DC, several Virtual Data Centers (VDCs) are currently restricted from issuing new provisioning jobs while redundancy is being restored for affected VMs. Original Incident: https://status.ionos.cloud/incidents/p6pjqxzgkh1g With this announcement we want to increase awareness about this current limitation. Impact Scope: Only customers and VDCs impacted by the original storage incident are affected by these provisioning limitations. Symptoms: Users may encounter error code VDC-5-12 when attempting to create or modify resources. Existing Workloads: All currently running VMs remain operational We will close this announcement once redundancy, as well as provisioning functionality, is fully restored.

Provisioning Service Degradation in FKB

May <var data-var='date'>13</var>, <var data-var='time'>06:56</var> UTC Resolved - This incident has been resolved, and all affected customers have been contacted directly via email. May <var data-var='date'>12</var>, <var data-var='time'>14:38</var> UTC Identified - We can confirm that these emails were sent out in error. There are no customer 'to-do's / calls-to-action, and we will send out an informational update to all affected customers as soon as possible. May <var data-var='date'>12</var>, <var data-var='time'>08:50</var> UTC Investigating - We are aware that, starting this morning, multiple customers have received an automated email from our Accounting Team advising that their Umsatzsteuer- / VAT ID numbers could not be verified. We are currently investigating this issue, and expect to send out follow-up emails to the affected customers once we know more.

Suspected Issues with USt- / VAT ID verification

May <var data-var='date'>13</var>, <var data-var='time'>06:30</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'>13</var>, <var data-var='time'>05:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. May <var data-var='date'> 8</var>, <var data-var='time'>16:40</var> UTC Scheduled - We would like to inform you that regular maintenance of the Cloud Panel is due to be carried out. During this time, access to the Cloud Panel will be limited while access to the vSphere Clients, NSX Managers and the management VPN themselves will not be impacted. Availability and accessibility of your Private Cloud resources will remain unaffected.

May <var data-var='date'>11</var>, <var data-var='time'>21:16</var> UTC Resolved - This incident has been resolved. May <var data-var='date'>11</var>, <var data-var='time'>19:05</var> UTC Monitoring - A fix has been implemented and we are monitoring the results. May <var data-var='date'>11</var>, <var data-var='time'>17:53</var> UTC Investigating - Some customers may experience connection problems to the control plane and degraded functionality of kubernetes

Partial Connectivity Degradation to Control Plane Affecting Kubernetes Operations

May <var data-var='date'>11</var>, <var data-var='time'>08:30</var> UTC Resolved - We are marking this incident as resolved. A RCA will be published here once it is compiled. May <var data-var='date'> 8</var>, <var data-var='time'>20:42</var> UTC Monitoring - The rollback was completed successfully. The team is currently checking the affected resources for potential residual inconsistencies. We are setting this incident into monitoring status. May <var data-var='date'> 8</var>, <var data-var='time'>18:42</var> UTC Update - We are currently rolling out the correction. We expect this to take several minutes and will update this page once the rollout is completed. May <var data-var='date'> 8</var>, <var data-var='time'>17:13</var> UTC Update - The team is now preparing to safely rollback identified changes on affected resources. May <var data-var='date'> 8</var>, <var data-var='time'>16:29</var> UTC Update - The team continues to audit affected resources to verify that all remaining inadvertent configuration changes are reverted. May <var data-var='date'> 8</var>, <var data-var='time'>15:52</var> UTC Identified - Our Kubernetes engineering team has identified the root cause of the issue. The incident stemmed from a defect in a configuration filtering mechanism. We are currently implementing mitigation steps and will provide further updates on our progress here. May <var data-var='date'> 8</var>, <var data-var='time'>15:15</var> UTC Investigating - Some customers may experience connection problems to the control plane and degraded functionality of kubernetes. Our engineers are working on a fix.

K8s Control Planes not available

May <var data-var='date'> 7</var>, <var data-var='time'>10:05</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'> 7</var>, <var data-var='time'>09:52</var> UTC Scheduled - As part of our commitment to delivering industry standard services, the two native IONOS AI Model Hub API endpoints — /models and /predictions — that were deprecated 3 months ago have now been disabled. The OpenAI-compatible API is not affected — only the native IONOS API endpoints have been removed, specifically: - https://inference.de-txl.ionos.com/models - https://inference.de-txl.ionos.com/models/{modelId}/predictions Our API specifications have been updated to reflect their absence, and for more information, please refer to https://api.ionos.com/docs/inference-openai/v1 or the previous email announcements.

Final Notice: Removal of native /predictions and /models API endpoints

May <var data-var='date'> 6</var>, <var data-var='time'>21:59</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'> 6</var>, <var data-var='time'>19:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. May <var data-var='date'> 6</var>, <var data-var='time'>18:58</var> UTC Scheduled - We will be performing an important maintenance on the gateways that connect virtual machines and storage in our DE/TXL (Berlin) location. The work updates the gateways to a new stable software version, ensuring continued security support and bringing the platform onto a modern operating system baseline. The maintenance is scheduled from 19:00 to 21:59 UTC on 6 May 2026 (21:00 to 23:59 CEST, Berlin time). The maintenance is carried out in two sequential phases across redundant systems so that services remain available throughout the window. Existing virtual machines and volumes are expected to continue running normally. However, creating new volumes or new virtual machines in the affected location may be briefly delayed or fail during the maintenance, and should be retried once the work is complete. Our engineering team will actively monitor the systems throughout the entire maintenance window and is prepared to respond immediately to any unexpected issues. No customer action is required. We will update this notice if the window changes or if any unexpected impact occurs. Affected services: Compute, Network, Provisioning Location: Location DE/TXL

Gateway upgrade in DE/TXL

May <var data-var='date'> 6</var>, <var data-var='time'>06:00</var> UTC Resolved - The Object Storage key creation is fixed, so new keys can be created and used. May <var data-var='date'> 5</var>, <var data-var='time'>14:36</var> UTC Monitoring - Object Storage key creation is back working, you can create new access keys now. However, we keep monitoring the behaviour. May <var data-var='date'> 5</var>, <var data-var='time'>07:47</var> UTC Investigating - We are currently investigating a general problem with our Object Storage Access Key creation. Currently, all new key creations are failing, so new keys can not be used. Old working keys are not affected, they are working as usual. Please be aware that the DCD frontend doesn't always reflect the key state properly, so to request the correct key status, please use the API.

Object Storage Service Restrictions: New keys can not be created

May <var data-var='date'> 6</var>, <var data-var='time'>05:58</var> UTC Resolved - The incident is over, all K8s control planes were back and operational yesterday. No further issues occurred. May <var data-var='date'> 5</var>, <var data-var='time'>17:06</var> UTC Monitoring - The team identified the issue and applied a fix, control planes are back now. We keep monitoring the situation. May <var data-var='date'> 5</var>, <var data-var='time'>16:06</var> UTC Investigating - We currently face outages of a high number of K8s control planes, mainly in Frankfurt. This could impact K8s workload changes for several customers. Our Teams are working on a fix.

Managed Kubernetes - Partial Connectivity Degradation to Control Planes

May <var data-var='date'> 6</var>, <var data-var='time'>05:55</var> UTC Resolved - The incident is over, Provisioning is back working normally. We are working on the RCA and publish it here asap. May <var data-var='date'> 4</var>, <var data-var='time'>15:33</var> UTC Monitoring - A fix has been implemented and we are monitoring the results. May <var data-var='date'> 4</var>, <var data-var='time'>13:04</var> UTC Investigating - On our ongoing provisioning resolution work, we had to set the Managed K8s service to "read-only", means no Cluster or Nodepool or Autoscale actions are possible at the moment, while the running workloads are not affected. We will let you know asap when the K8s system is back. May <var data-var='date'> 4</var>, <var data-var='time'>12:00</var> UTC Monitoring - A fix has been implemented and we are monitoring the results. May <var data-var='date'> 4</var>, <var data-var='time'>11:42</var> UTC Update - We are continuing to work on a fix for this issue. May <var data-var='date'> 4</var>, <var data-var='time'>11:26</var> UTC Update - Provisioning was enabled again, however we are still working on the overall resolution. May <var data-var='date'> 4</var>, <var data-var='time'>10:18</var> UTC Update - We temporarily deactivated provisioning in order to fix the underlying issue. May <var data-var='date'> 4</var>, <var data-var='time'>09:53</var> UTC Update - We are continuing to work on a fix for this issue. May <var data-var='date'> 4</var>, <var data-var='time'>09:22</var> UTC Update - We are continuing to work on a fix for this issue. May <var data-var='date'> 4</var>, <var data-var='time'>08:45</var> UTC Update - We are continuing to work on a fix for this issue. May <var data-var='date'> 4</var>, <var data-var='time'>04:10</var> UTC Identified - Currently, there is an increased processing time for provisioning orders initiated via Data Center Designer or API. Customers may experience timeouts or errors in some provisioning-related operations. Occasionally, connections to the Data Center Designer may be interrupted. May <var data-var='date'> 3</var>, <var data-var='time'>21:22</var> UTC Monitoring - A fix has been implemented and we are monitoring the results. May <var data-var='date'> 3</var>, <var data-var='time'>18:53</var> UTC Identified - Currently, there is an increased processing time for provisioning orders that are initiated via Data Center Designer or API. Occasionally, connections may be lost in the direction of the Data Center Designer. Availability and accessibility of your virtual data center resources will remain unaffected. We will inform you as soon as the functionality has been restored.

Limited access to provisioning services, DCD, Managed Kubernetes

May <var data-var='date'> 5</var>, <var data-var='time'>22:00</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'> 5</var>, <var data-var='time'>19:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Apr <var data-var='date'>30</var>, <var data-var='time'>08:07</var> UTC Scheduled - We will perform an update of firewall rules on servers in Berlin. This process is generally impact-free, however, it is possible that while the rules are being applied, some packets might be dropped. These issues generally recover immediately, so we do not expect any prolonged outage. Affected services: Network Location: Location DE/TXL

Firewall Rule Update

May <var data-var='date'> 4</var>, <var data-var='time'>21:59</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'> 4</var>, <var data-var='time'>17:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Apr <var data-var='date'>30</var>, <var data-var='time'>09:34</var> UTC Scheduled - We will be performing scheduled maintenance on the gateways that connect virtual machines and storage in our DE/TXL (Berlin) location. The work updates the gateways to a new stable software version, ensuring continued security support and bringing the platform onto a modern operating system baseline. The maintenance is carried out in two sequential phases across redundant systems so that services remain available throughout the window. Existing virtual machines and volumes are expected to continue running normally. However, creating new volumes or new virtual machines in the affected location may be briefly delayed or fail during the maintenance, and should be retried once the work is complete. Our engineering team will actively monitor the systems throughout the entire maintenance window and is prepared to respond immediately to any unexpected issues. We will update this notice if the window changes or if any unexpected impact occurs. Affected services: Network, Provisioning, Storage Location: Location DE/TXL

May <var data-var='date'> 4</var>, <var data-var='time'>08:00</var> UTC Completed - The scheduled maintenance has been completed. May <var data-var='date'> 1</var>, <var data-var='time'>08:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Apr <var data-var='date'>21</var>, <var data-var='time'>16:58</var> UTC Scheduled - As communicated in an email notification earlier this year, we are finalizing the retirement of the legacy SYNCHRONOUS replication mode. To ensure continued stability, all remaining PostgreSQL clusters will be automatically migrated during their first scheduled maintenance window after May 4, 2026. What is changing? - Automatic Migration: Your cluster will be transitioned to ASYNCHRONOUS mode. - Impact: You will experience a brief restart during the maintenance window. While you may see improved write performance, please note that ASYNCHRONOUS mode prioritizes speed over strict data acknowledgment. Action Required for Strong Consistency If your workload requires a zero-data-loss guarantee, you must manually upgrade to STRICTLY_SYNCHRONOUS via the API no later than May 1, 2026: - Scale Replicas: Increase your cluster to 3 or more replicas. - Update API: Set the synchronization mode to STRICTLY_SYNCHRONOUS. Affected services: Database as a Service (DBaaS) Location: Global Services

Final Notice: Update to PostgreSQL Replication Mode

Apr <var data-var='date'>29</var>, <var data-var='time'>22:30</var> UTC Completed - The scheduled maintenance has been completed. Apr <var data-var='date'>29</var>, <var data-var='time'>18:30</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Apr <var data-var='date'>27</var>, <var data-var='time'>09:15</var> UTC Scheduled - We are performing routine network optimization for our Database Quota Service, the system responsible for managing resource limits across your database environments. To achieve this, we are updating our Border Gateway Protocol (BGP) configurations - essentially the "digital maps" that guide traffic to our servers. These updates ensure your service remains fast and reliable by routing your requests through the most efficient paths possible. Impact and Risk Minimization - Zero Downtime: This update is designed to run seamlessly in the background. Your service will remain online throughout the process. - Minimal Latency: You may experience a brief, minor increase in response time (a "latency spike") lasting only a few seconds. - Staged Rollout: To ensure stability, this update will be deployed one location at a time. Our engineering team will be monitoring live traffic throughout the entire transition. Affected services: Network Location: Location DE/TXL, Location ES/VIT, Location FR/PAR, Location GB/BHX, Location GB/LHR, Location US/LAS, Location US/MCI

BGP Setup: Multi-Location Quota Service Integration (LHR, BHX1, VIT, MCI1, PAR2, LAS, TXL)

Apr <var data-var='date'>29</var>, <var data-var='time'>22:00</var> UTC Completed - The scheduled maintenance has been completed. Apr <var data-var='date'>29</var>, <var data-var='time'>17:01</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Apr <var data-var='date'>27</var>, <var data-var='time'>15:37</var> UTC Scheduled - We will be performing scheduled maintenance on the network infrastructure that connects virtual machines and storage in our DE/TXL (Berlin) location.. The work updates this infrastructure to a new stable software version. The maintenance is carried out in two sequential phases across redundant systems so that services remain available throughout the window. Existing virtual machines and volumes are expected to continue running normally. However, creating new volumes or new virtual machines in the affected cluster may be briefly delayed or fail during the maintenance, and should be retried once the work is complete. Affected services: Network, Provisioning, Storage Location: Location DE/TXL

Is IONOS Cloud down?

IONOS Cloud status is UP

Lastest published events

Planned infrastructure upgrade — Monitoring & Logging Services (PAR, LHR, FRA, TXL)

Network Outage in Worcester

Cloud Panel Maintenance

IONOS Cloud Services, Components and Regions

Recent IONOS Cloud events

MongoDB Playground: 30-day cluster lifecycle policy takes effect

IAM Cluster Migration

Cloud Panel Maintenance

Planned infrastructure upgrade — Monitoring & Logging Services (PAR, LHR, FRA, TXL)

Network Outage in Worcester

Cloud Panel Maintenance

Get your FREE account now,
5 monitors included!

Is IONOS Cloud down?

IONOS Cloud status is UP

Lastest published events

Planned infrastructure upgrade — Monitoring & Logging Services (PAR, LHR, FRA, TXL)

Network Outage in Worcester

Cloud Panel Maintenance

IONOS Cloud Services, Components and Regions

Recent IONOS Cloud events

MongoDB Playground: 30-day cluster lifecycle policy takes effect

IAM Cluster Migration

Cloud Panel Maintenance

Planned infrastructure upgrade — Monitoring & Logging Services (PAR, LHR, FRA, TXL)

Network Outage in Worcester

Cloud Panel Maintenance

Get your FREE account now,5 monitors included!

Get your FREE account now,
5 monitors included!