THIS IS A SCHEDULED EVENT Aug <var data-var='date'>31</var>, <var data-var='time'>14:00</var> - <var data-var='time'>16:00</var> UTC Aug <var data-var='date'>13</var>, <var data-var='time'>12:32</var> UTC Scheduled - Overview We are officially transitioning IONOS In-Memory DB to a new, enhanced API v2 architecture. The new v2 platform is powered by Valkey (an open-source key/value datastore maintained by the Linux Foundation) and provides significant upgrades to snapshot retention and observability. Because of the architectural changes, automatic migration is not possible. All customers must manually migrate their data and update their endpoints to v2 before the end-of-life deadline to avoid service interruption. Deprecation Timeline v1 Cluster Creation Disabled - August 4, 2026 - It is no longer possible to provision new In-Memory DB v1 clusters. Existing clusters continue to operate normally. In-Memory DB v1 End of Life - August 31, 2026 - Critical Deadline: Full decommissioning of API v1. All remaining v1 instances will be permanently switched off on this date. New Snapshot Pricing Applies - September 1, 2026 - Standard pricing for the enhanced v2 snapshot features takes effect. (All v2 snapshots are included at no additional cost prior to this date). Required Migration Steps To ensure your applications continue to run smoothly, please complete the following migration procedure before August 31, 2026: 1. Provision a v2 Instance: API, DCD and SDK access available now - Create a new In-Memory DB v2 instance using the v2 API documentation. You can select Valkey versions 8, 8.1, or 9. 2. Migrate Your Data: Only if data persistence is required - Load your existing v1 data into the new v2 instance. Because Valkey is compatible with standard Redis clients and tools, you can use your existing toolset for this transfer. 3. Update Application Endpoints - Update your application connection strings to point to the new v2 instance. No application code changes are required, as Valkey acts as a drop-in replacement. What to Expect in In-Memory DB v2 - Powered by Valkey: Built on the robust, open-source datastore supported by the Linux Foundation. Fully compatible with standard Redis clients. - Enhanced Snapshots: Move from single-snapshot limitations to multi-snapshot retention. Keep backups for up to 365 days for long-term point-in-time recovery. (Note: New snapshot pricing applies starting Sept 1, 2026, reflecting the upgraded infrastructure). - IONOS Observability (Optional): Seamlessly integrate your database with IONOS Observability to track performance metrics and logs. This feature is entirely optional and billed separately upon enablement. If you require assistance with your migration plan or have any questions about the transition to Valkey, please refer to https://docs.ionos.com/cloud/databases/in-memory-db/how-tos/migrate-from-v1-v2 or contact our Customer Support team. Affected services: Database as a Service (DBaaS) Location: Global Services

Action Required: IONOS In-Memory DB API v1 Full Deprecation

THIS IS A SCHEDULED EVENT Aug <var data-var='date'>24</var>, <var data-var='time'>14:00</var> UTC &nbsp;-&nbsp; Aug <var data-var='date'>28</var>, <var data-var='time'>06:00</var> UTC Aug <var data-var='date'>13</var>, <var data-var='time'>10:13</var> UTC Scheduled - Overview We are rolling out an important upgrade to IONOS MariaDB. All existing MariaDB clusters utilizing API v1 will be automatically migrated to the new MariaDB API v2. This migration unlocks several new capabilities, including support for newer MariaDB versions, extended backup retention (up to 365 days for point-in-time recovery), and integration with IONOS Observability for performance monitoring. Customer Impact & Migration Process - Zero Downtime: Your databases will remain fully accessible throughout the entire migration process. - No Connection Changes: Your existing connection strings will continue to work without any modifications. - Automated: The migration of the cluster itself requires no manual intervention on your part. Key Dates & Milestones - August 17, 2026 - v1 Cluster Creation Disabled: It will no longer be possible to provision new MariaDB v1 clusters. - August 31, 2026 - MariaDB API v1 End of Life: API v1 will be fully deprecated. All integrations must be updated to v2. Action Required (Post-Migration) While the cluster migration is automated, you will need to update your integrations and tools to interface with the new v2 environment before the August 31, 2026 deadline: - API Integrations: Update your scripts and API calls to use the new MariaDB v2 API. - Infrastructure as Code: Update your Terraform configurations to utilize the MariaDB v2 provider. - SDKs: Upgrade any application integrations to the MariaDB v2 SDK. - Version Upgrades (If applicable): If you are currently running MariaDB 10.6, please plan an upgrade to a higher version (10.11, 11.4, 11.8, or 12.3) before the end of August 2026. What's New in MariaDB API v2? - New Version Support: Added support for MariaDB 11.4, 11.8 and 12.3 alongside 10.6 and 10.11. - Advanced Backups: Maintain backups with a retention period of up to 365 days, enabling long-term point-in-time recovery. - Observability Integration: Opt-in to connect MariaDB v2 with IONOS Observability for detailed performance metrics (Note: Observability usage is billed separately). If you experience any issues or have questions regarding this migration, please reach out to our support team at support@cloud.ionos.com. Affected services: Database as a Service (DBaaS) Location: Global Services

Automated Migration to IONOS MariaDB API v2

Aug <var data-var='date'>21</var>, <var data-var='time'>08:18</var> UTC Identified - The issue has been identified and a fix is being implemented. Aug <var data-var='date'>21</var>, <var data-var='time'>07:52</var> UTC Investigating - Currently it's not possible to reserve or handle IP blocks, neither in DCD, nor via API. Our teams are investigating the issue. We will keep you updated.

IP Reservation Not Possible

Aug <var data-var='date'>20</var>, <var data-var='time'>17:00</var> UTC Completed - The scheduled maintenance has been completed. Aug <var data-var='date'>20</var>, <var data-var='time'>14:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Aug <var data-var='date'>20</var>, <var data-var='time'>11:56</var> UTC Scheduled - To further improve performance and stability of our Control Plane, we are conducting a maintenance on Managed Kubernetes in Frankfurt (DE/FRA), Thu 20 Aug 16:00–19:00 CEST. Some clusters will have their Kubernetes API briefly unavailable — typically under 2 minutes, 5 minutes at most. Worker nodes and running workloads are unaffected. No action required. Affected services: Managed Kubernetes Location: Location DE/FRA

Scheduled maintenance: Managed Kubernetes — Frankfurt (de/fra)

Aug <var data-var='date'>20</var>, <var data-var='time'>08:18</var> UTC Resolved - We managed to get back to normal capacity, so Support is back to normal availability. Thank you for the patience. Aug <var data-var='date'>17</var>, <var data-var='time'>13:31</var> UTC Update - The situation is still unchanged, so best would be to please reach out via email. Aug <var data-var='date'>14</var>, <var data-var='time'>14:50</var> UTC Identified - There may be periods of increased waiting times when calling IONOS Cloud Support by phone. We ask Customers and Partners to contact Cloud Support via the DCD Form or Email, instead.

Cloud Support: Telephone Support reduced capacity

Aug <var data-var='date'>17</var>, <var data-var='time'>16:00</var> UTC Completed - The scheduled maintenance has been completed. Aug <var data-var='date'>17</var>, <var data-var='time'>14:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Aug <var data-var='date'> 6</var>, <var data-var='time'>13:39</var> UTC Scheduled - Effective Aug 17, 2026, IONOS Cloud will permanently disable the creation of new DBaaS MariaDB clusters via API v1. This is a preliminary step in our transition to the upgraded MariaDB v2 infrastructure. What does this mean for you? - New Cluster Provisions: Any automated scripts, CI/CD pipelines, SDKs, or IaC tools (e.g., Terraform) attempting to create new MariaDB clusters using API v1 after Aug 17, 2026, will be rejected. - Existing Clusters: There is no impact on existing MariaDB v1 clusters. All running v1 instances will remain fully operational and accessible as usual. Required Actions for New Deployments To deploy new MariaDB clusters going forward, you must transition your provisioning automation to MariaDB v2: - Update API Calls & Integrations: Switch your scripts, SDKs, and Terraform configurations to use the MariaDB v2 API and providers. - Review Supported Versions: MariaDB v2 supports versions 10.11, 11.4, 11.8 and 12.3. Looking Ahead: Automated Cluster Migrations Existing MariaDB v1 clusters will be automatically migrated to the v2 infrastructure by IONOS with zero downtime. Connection endpoints will remain unchanged. You will receive separate status updates and communications as the migration rollout approaches. If you have questions or need technical assistance updating your workflows to API v2, please contact our Customer Support team at support@cloud.ionos.com. Affected services: Database as a Service (DBaaS) Location: Global Services

Disabling MariaDB Cluster Creation via API v1

Aug <var data-var='date'>17</var>, <var data-var='time'>05:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Aug <var data-var='date'>12</var>, <var data-var='time'>12:34</var> UTC Scheduled - IONOS Cloud will perform an automated migration of all DBaaS PostgreSQL clusters from the v1 infrastructure to our upgraded v2 infrastructure. This upgrade introduces several key platform enhancements, including lower-latency regional API endpoints, optional native Observability integration (IONOS Logging and Monitoring), and mandatory SSD Premium storage for higher, consistent I/O performance. What this means for you: - Automated Migration: The migration is fully managed by IONOS Cloud. No manual migration steps are required for your database clusters. - Expected Downtime: This brief downtime (typically lasting a few seconds) applies per individual cluster only during its specific migration window. It does not impact the availability of the entire DBaaS service. We recognize that even brief unavailability can affect your operations, and ensuring your service continuity remains our highest priority throughout this transition. - Database Connections: Your cluster connection endpoints will remain unchanged. Your applications will automatically reconnect once the migration process finishes. Required Actions for API & Programmatic Users If you manage your PostgreSQL clusters programmatically via APIs, SDKs, or Infrastructure as Code (IaC) tools (e.g., Terraform), you must take action before the migration begins: - Switch to Token Authentication: PostgreSQL v2 does not support BASIC authentication for cluster management. You must switch your tools to use TOKEN authentication before the 14th of August, 2026, to prevent management access disruption. - Instructions for generating authentication tokens can be found in the IONOS Cloud Token Manager Documentation (see https://docs.ionos.com/cloud/set-up-ionos-cloud/management/identity-access-management/token-manager for more information). - Note: If you already use TOKEN authentication or do not manage your clusters programmatically, no action is required. Important Storage & Price Changes Notice Regarding Infrastructure Upgrades & Fees: To ensure peak performance, all PostgreSQL v2 clusters run exclusively on SSD Premium storage. - Clusters currently running on HDD or SSD Standard storage will be automatically upgraded to SSD Premium as part of this migration and will subsequently be billed at the standard SSD Premium rate. - Optional usage of the new IONOS Logging and Monitoring integration is billed separately. As these infrastructure updates constitute changes to the fees applicable to your service, you retain the right to terminate your contract without notice upon the effectiveness of these changes, in accordance with our General Terms and Conditions. For further technical details regarding the new infrastructure features, please consult the official IONOS Cloud DBaaS PostgreSQL documentation. Affected services: Database as a Service (DBaaS) Location: Global Services

Automated DBaaS PostgreSQL v1 to v2 Infrastructure Migration

Aug <var data-var='date'>14</var>, <var data-var='time'>13:34</var> UTC Resolved - This incident has been resolved. Aug <var data-var='date'>14</var>, <var data-var='time'>12:42</var> UTC Monitoring - A fix has been implemented and we are monitoring the results. Aug <var data-var='date'>14</var>, <var data-var='time'>10:51</var> UTC Identified - We are currently reports of error VDC-14-1836 during provisioning operations. Our provisioning team is informed and is preparing a hotfix.

Provisioning: VDC-14-1836

Aug <var data-var='date'>14</var>, <var data-var='time'>08:04</var> UTC Resolved - We were able to resolve this issue, it's back to normal now. Aug <var data-var='date'>13</var>, <var data-var='time'>00:49</var> UTC Investigating - We are currently investigating reports of increased AI Model Hub error rates and latencies. More details will be shared as they become available.

AI Model Hub - Service Degradations

Aug <var data-var='date'>12</var>, <var data-var='time'>23:00</var> UTC Completed - The scheduled maintenance has been completed. Aug <var data-var='date'>12</var>, <var data-var='time'>20:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Aug <var data-var='date'>11</var>, <var data-var='time'>07:10</var> UTC Scheduled - We will be performing a network maintenance in DE/FRA and DE/FRA/2 that includes updating routing filters. While no impact is expected, in some cases, you might notice increased latency for 5-10 seconds due to routing convergence. The availability of your virtual data center resources will remain unaffected.

Network maintenance

Aug <var data-var='date'>12</var>, <var data-var='time'>17:00</var> UTC Completed - The scheduled maintenance has been completed. Aug <var data-var='date'>12</var>, <var data-var='time'>15:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Aug <var data-var='date'> 5</var>, <var data-var='time'>09:03</var> UTC Scheduled - We will be routing provisioning traffic to a new setup to improve stability and geo-redundancy for our customers. As a result, provisioning services — including the Cloud API and Data Center Designer — may be temporarily unavailable for a few minutes. Since ionosctl, Terraform, and our SDKs depend on the Cloud API, these tools will also be affected during this time. Customer workloads will remain unaffected. Please follow https://status.ionos.cloud/ for real-time updates. Affected services: Cloud API, Data Center Designer (DCD), Provisioning Location: APIs and Frontends, Location DE/FKB, Location DE/FRA, Location DE/FRA/2, Location DE/TXL, Location ES/VIT, Location FR/PAR, Location GB/BHX, Location GB/GLO, Location GB/LHR, Location US/EWR, Location US/LAS, Location US/MCI

Switch provisioning setup

Aug <var data-var='date'>12</var>, <var data-var='time'>11:52</var> UTC Resolved - This incident has been resolved. Aug <var data-var='date'>11</var>, <var data-var='time'>19:24</var> UTC Monitoring - We confirm that the provisioning service has recovered and is operating normally. Our teams will continue to monitor the environment to ensure its stability and continued operation. Aug <var data-var='date'>11</var>, <var data-var='time'>16:37</var> UTC Update - We are still seeing residual 500 errors from the Cloud API and are working towards resolving the remaining service degradation. Aug <var data-var='date'>11</var>, <var data-var='time'>16:23</var> UTC Identified - We have identified a likely culprit. The Provisioning Team has implemented a mitigation. We see the performance of the service stabilizing. Aug <var data-var='date'>11</var>, <var data-var='time'>16:05</var> UTC Investigating - 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

Aug <var data-var='date'>11</var>, <var data-var='time'>19:00</var> UTC Completed - The scheduled maintenance has been completed. Aug <var data-var='date'>11</var>, <var data-var='time'>17:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Aug <var data-var='date'> 6</var>, <var data-var='time'>13:40</var> UTC Scheduled - We are performing network maintenance that includes updating routing filters. Generally this has no impact, but in some cases, due to routing convergence, this can cause an impact of 5-10 seconds. Affected services: Network Location: Location DE/FRA

Network Maintenance

Aug <var data-var='date'>10</var>, <var data-var='time'>19:58</var> UTC Resolved - We are marking this incident as resolved. The measures already put into place have had the desired effect on the service and have improved performance and stability. While this incident is marked as resolved, we are continuing executing on our action plan to improve the performance and reliability of our Managed Kubernetes Control Planes. Our current focus: - Further load balancing on our Control Plane Clusters - Migration of control planes to improved infrastructure Aug <var data-var='date'> 7</var>, <var data-var='time'>05:06</var> UTC Update - Migration of customer workloads on the first control plane cluster has been completed ahead of schedule. Customer clusters have been redistributed across expanded infrastructure and all migrated workloads are running without issues. We continue to observe stable control plane performance with no new disruptions reported. Aug <var data-var='date'> 6</var>, <var data-var='time'>08:04</var> UTC Monitoring - Memory limit adjustments have been fully rolled out across all control plane clusters and are showing positive effects. We have significantly expanded the underlying infrastructure capacity and migration of customer workloads is progressing well. We are observing substantial improvements in control plane stability and performance. The recurring disruption patterns described in earlier updates are no longer present. Migration work will continue throughout the day. We will provide an update once migrations are completed or if any changes in status occur. Aug <var data-var='date'> 5</var>, <var data-var='time'>20:43</var> UTC Update - Memory limit adjustments and migration have had positive effects on the first control plane cluster. Customer situated in the first control plane cluster should already see substantial improvements in performance and stability. We have started to roll out memory adjustments in the remaining control plane cluster, as well. Rolling out the memory limits can lead to temporary unavailability of affected control planes. These interruptions should be brief and will not affect running workloads. After memory limit adjustments are fully rolled out on the second control plane cluster, horizontal scaling and migrations will resume on both control plane clusters for the next hours until workload is distributed optimally. Aug <var data-var='date'> 5</var>, <var data-var='time'>10:07</var> UTC Update - Migration has been picked up again. We already see encouraging results after completion of first batches. In the next hours we focus on completing the migration and horizontal scaling. During the migration, single etcds can be temporarily unavailable for time periods lasting around 30 seconds. We expect further performance and stability improvements for all customers during and after the migration. Aug <var data-var='date'> 5</var>, <var data-var='time'>06:23</var> UTC Identified - Migration of the first batches has been completed. The Kubernetes Team has identified a remaining issue preventing further migration. We are setting this incident back to active until the issue is resolved and the migration completed. Aug <var data-var='date'> 4</var>, <var data-var='time'>21:11</var> UTC Monitoring - Memory adjustments have been rolled out and show positive effects. We are starting the migrations planned to further improve control plane performance for all our customers. We estimate that the migration will be completed in the next hours. Control Plane performance is expected to improve already during the migration. We are setting this incident into Monitoring status and will provide an update once the migration is completed. Aug <var data-var='date'> 4</var>, <var data-var='time'>16:23</var> UTC Update - Our plans for further horizontal scaling of the control plane are progressing. We expect to be able to do a dry run and further testing within the next hours, before we proceed with migrations. We aim to finish work on horizontal scaling until EOD. We are rolling out memory configuration improvements in parallel. Aug <var data-var='date'> 4</var>, <var data-var='time'>14:37</var> UTC Update - We are currently rolling out memory scaling measures to address recurring stability issues during compaction operations on the affected etcd clusters. Additionally, we are planning to roll out further horizontal scaling for the affected clusters today. We will provide another update once these measures have been applied and we can assess their impact. Aug <var data-var='date'> 4</var>, <var data-var='time'>13:14</var> UTC Update - During a service rollout today, a subset of control planes experienced temporary restarts. Affected customers may notice brief API unavailability while these control planes recover. The team is monitoring the recovery. Separately, work on improving infrastructure capacity and load distribution continues as described in our initial update. We will post another update once the affected control planes have fully stabilized. Aug <var data-var='date'> 4</var>, <var data-var='time'>10:24</var> UTC Identified - We are aware of intermittent control plane unavailability affecting a subset of Managed Kubernetes customers. Affected customers may experience API call failures, deployment timeouts, and temporary disruption of cluster management operations. Our engineering team is actively working on both immediate mitigations and longer-term architectural improvements. Several mitigations have already been deployed, including maintenance schedule optimization, compaction regression fixes, and storage performance improvements. Additional measures - including infrastructure migration, dedicated event etcd clusters, improved load balancing, and horizontal scaling - are in progress. We are providing regular updates on this page. Customers experiencing issues are encouraged to subscribe to this incident for timely notifications.

Managed Kubernetes - Intermittent Control Plane Unavailability

Aug <var data-var='date'> 6</var>, <var data-var='time'>17:00</var> UTC Completed - The scheduled maintenance has been completed. Aug <var data-var='date'> 3</var>, <var data-var='time'>09:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Jul <var data-var='date'>16</var>, <var data-var='time'>13:34</var> UTC Scheduled - IONOS Cloud will perform an automated migration of all DBaaS PostgreSQL clusters from the v1 infrastructure to our upgraded v2 infrastructure. This upgrade introduces several key platform enhancements, including lower-latency regional API endpoints, optional native Observability integration (IONOS Logging and Monitoring), and mandatory SSD Premium storage for higher, consistent I/O performance. What this means for you: - Automated Migration: The migration is fully managed by IONOS Cloud. No manual migration steps are required for your database clusters. - Expected Downtime: This brief downtime (typically lasting a few seconds) applies per individual cluster only during its specific migration window. It does not impact the availability of the entire DBaaS service. We recognize that even brief unavailability can affect your operations, and ensuring your service continuity remains our highest priority throughout this transition. - Database Connections: Your cluster connection endpoints will remain unchanged. Your applications will automatically reconnect once the migration process finishes. Required Actions for API & Programmatic Users If you manage your PostgreSQL clusters programmatically via APIs, SDKs, or Infrastructure as Code (IaC) tools (e.g., Terraform), you must take action before the migration begins: - Switch to Token Authentication: PostgreSQL v2 does not support BASIC authentication for cluster management. You must switch your tools to use TOKEN authentication before July 29, 2026, to prevent management access disruption. - Instructions for generating authentication tokens can be found in the IONOS Cloud Token Manager Documentation [https://docs.ionos.com/cloud/set-up-ionos-cloud/management/identity-access-management/token-manager]. - Note: If you already use TOKEN authentication or do not manage your clusters programmatically, no action is required. Important Storage & Price Changes Notice Regarding Infrastructure Upgrades & Fees: To ensure peak performance, all PostgreSQL v2 clusters run exclusively on SSD Premium storage. - Clusters currently running on HDD or SSD Standard storage will be automatically upgraded to SSD Premium as part of this migration and will subsequently be billed at the standard SSD Premium rate. - Optional usage of the new IONOS Logging and Monitoring integration is billed separately. As these infrastructure updates constitute changes to the fees applicable to your service, you retain the right to terminate your contract without notice upon the effectiveness of these changes, in accordance with our General Terms and Conditions. For further technical details regarding the new infrastructure features, please consult the official IONOS Cloud DBaaS PostgreSQL documentation. Affected services: Database as a Service (DBaaS) Location: Global Services

Aug <var data-var='date'> 4</var>, <var data-var='time'>10:02</var> UTC Resolved - We were able to assign additional personnel and will set this status page to resolved. Aug <var data-var='date'> 4</var>, <var data-var='time'>08:20</var> UTC Identified - IONOS Cloud Support is temporarily not always available via phone. We ask Customers and Partners to contact Cloud Support via the DCD Form or Email, instead.

Cloud Support: Telephone Line Availability Degraded

Aug <var data-var='date'> 4</var>, <var data-var='time'>10:01</var> UTC Resolved - we are marking this incident as resolved as the underlying storage issue has been resolved. We will create a follow up incident for Managed Kubernetes performance and stability issues to avoid confusion. Jul <var data-var='date'>19</var>, <var data-var='time'>12:21</var> UTC Update - The migration of storages has been completed, which should prevent further issues with attaching storage. Migration of snapshot data is currently ongoing, so snapshot related activities might still fail to complete successfully. Jul <var data-var='date'>18</var>, <var data-var='time'>22:43</var> UTC Update - The first hardware replacement was unsuccessful. Another one is attempted. In the meanwhile a data migration is running to migrate data to another storage target. Due to the amount of data to be migrated the migration is estimated to take several hours. Jul <var data-var='date'>18</var>, <var data-var='time'>22:03</var> UTC Update - Hardware replacement was completed. Restoration of redundancy is continuing. Jul <var data-var='date'>18</var>, <var data-var='time'>21:31</var> UTC Update - Hardware replacement is being conducted. The team continues to mitigate acute storage provisioning issues until hardware replacement and recovery is completed to minimize customer impact. Jul <var data-var='date'>18</var>, <var data-var='time'>20:24</var> UTC Update - The team has encountered a complication during the recovery of the second storage server in the pair. Hardware needs to be replaced. Our datacenter team is working on this task. For customers still affected we are working on implementing a mitigation to unblock storage operations in parallel. Jul <var data-var='date'>18</var>, <var data-var='time'>19:27</var> UTC Update - Due to the ongoing restoration effort on the storage server customers might still see residual impact when attaching/detaching storage until redundancy is fully restored. We are resetting the impact of the service back to Degraded Performance. Jul <var data-var='date'>18</var>, <var data-var='time'>17:54</var> UTC Monitoring - The incident should now be mitigated. The affected storage server is currently getting restored. Once this is completed, redundancy will be fully restored. We do not see any remaining provisioning issues any longer. We are monitoring the situation and the restoration and will then set the incident to resolved. Jul <var data-var='date'>18</var>, <var data-var='time'>17:24</var> UTC Update - We have found an issue with one storage server belonging to a redundant storage server pair. Our team is implementing a mitigation. Jul <var data-var='date'>18</var>, <var data-var='time'>16:54</var> UTC Update - While provisioning block could be resolved, we are investigating an increased number of storage related errors. We are directing attention to these remaining issues. Customers could still see issues with attaching storages on Kubernetes. Jul <var data-var='date'>18</var>, <var data-var='time'>15:51</var> UTC Update - Storage issue has successfully been resolved, however, job provisioning is currently not progressing successfully. Our provisioning team is investigating. Jul <var data-var='date'>18</var>, <var data-var='time'>15:03</var> UTC Update - Our storage team has confirmed the suspected culprit. We are currently mitigating the issue and will monitor provisioning job execution afterwards. Jul <var data-var='date'>18</var>, <var data-var='time'>14:47</var> UTC Update - We have narrowed down the issue and believe we have the culprit identified. We are currently confirming the finding. Jul <var data-var='date'>18</var>, <var data-var='time'>14:26</var> UTC Identified - We have identified a spike in our provisioning engine queue that is a likely root cause for the issues observed. Our provisioning team is informed and has joined the response. Jul <var data-var='date'>18</var>, <var data-var='time'>13:55</var> UTC Update - Initial investigation makes a network connectivity issue unlikely. The team is focusing investigation on Managed Kubernetes side. Jul <var data-var='date'>18</var>, <var data-var='time'>13:33</var> UTC Investigating - We are currently investigating a suspected network connectivity issue influencing the MK8s service. We will keep the status page updated with new information as they become available.

MK8s - Connectivity Issue

Aug <var data-var='date'> 3</var>, <var data-var='time'>14:00</var> UTC Completed - The scheduled maintenance has been completed. Aug <var data-var='date'> 3</var>, <var data-var='time'>10:00</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Jul <var data-var='date'>23</var>, <var data-var='time'>13:33</var> UTC Scheduled - Effective Aug 3rd, 2026, IONOS Cloud will permanently disable the creation of new In-Memory DB clusters via API v1. This is a preliminary step in our transition to the upgraded In-Memory DB v2 infrastructure (powered by Valkey). What does this mean for you? - New Deployments: Any automated scripts, CI/CD pipelines, SDKs, or IaC tools attempting to provision new In-Memory DB clusters using API v1 after Aug 3rd, 2026, will be rejected. - Existing Clusters: There is no impact on existing In-Memory DB v1 clusters. All running v1 instances will remain fully operational and accessible. Required Actions for New Clusters To deploy new In-Memory DB clusters going forward, you must transition your provisioning workflows to the In-Memory DB v2 API: - v2 API Documentation: https://api.ionos.com/docs/in-memory-db/v2/ - Client Compatibility: In-Memory DB v2 is powered by Valkey and remains fully compatible with standard Redis clients and tools (no application code changes required). Affected services: Database as a Service (DBaaS) Location: Global Services

Disabling In-Memory DB Cluster Creation via API v1

Jul <var data-var='date'>28</var>, <var data-var='time'>16:36</var> UTC Resolved - We are marking this incident as resolved as no further abnormalities could be detected. We will share an RCA as soon as it is compiled. Jul <var data-var='date'>28</var>, <var data-var='time'>13:54</var> UTC Monitoring - The DBaaS Team has performed a rollback of a change deployed prior that updated DNS services. We are seeing services recovering. We are monitoring the situation closely. Jul <var data-var='date'>28</var>, <var data-var='time'>13:51</var> UTC Identified - We have identified an issue with DNS. Our DBaaS Team is currently analyzing the service. A potential culprit has been identified. We will provide another update here latest 14:15 Jul <var data-var='date'>28</var>, <var data-var='time'>13:47</var> UTC Update - We are continuing to investigate this issue. Jul <var data-var='date'>28</var>, <var data-var='time'>13:46</var> UTC Investigating - We are currently investigating a connectivity issue impacting our DBaaS (MongoDB) services. Our team is working to resolve the problem, and we will update you as soon as full functionality has been restored.

Connectivity Issues with DBaaS (MongoDB)

Jul <var data-var='date'>28</var>, <var data-var='time'>12:19</var> UTC Resolved - We are marking this incident as resolved. To address the described performance and stability concerns, we have made the following changes: - Upgraded our AI Modelhub setup to increase overall model performance. - Rolled out improved monitoring and response tooling for high-load scenarios. - Replaced Llama 405B with Qwen 3.5 397B. - Officially deprecated Collections. We are confident these changes address these issues effectively and will help us provide an even better service moving forward. Thank you for your patience! Jun <var data-var='date'> 4</var>, <var data-var='time'>14:34</var> UTC Identified - The AI Model Hub is currently experiencing high demand. As a shared infrastructure environment, this temporary surge in utilization may result in increased latency and varied performance across the platform. Current Impacts - Increased Latency (TTFT): High GPU utilization may cause delayed responses (Time to First Token) when initiating model requests. We are continuously managing platform resources to maximize availability across all concurrent workloads. - Llama 405B Constraints: Due to its scale and high compute requirements, the Llama 405B model is particularly sensitive to traffic spikes, leading to potential timeouts or higher latency—we recommend switching to alternative models for time-critical workloads requiring faster response times. - Collections: Collections can also be influenced negatively by high demand and utilization. Please see the notes on new deployments in our documentation: https://docs.ionos.com/cloud/ai/ai-model-hub/how-tos/document-collections Recommendations: - To mitigate temporarily performance or availability issues, we encourage our customers and partners to implement (exponential backoff) retry mechanisms in their projects and pipelines. Usage peaks that lead in timeouts and degraded performance are usually transient. - We kindly ask our customers to not create additional Support Tickets for questions and reports related to the performance of models in the Model Hub. Our Product and Tech Teams are aware and are actively monitoring and working on improving the service to meet demand. - We ask Llama 405B users that face issues to consider a switch to GTP-OSS-120B instead. In most real world use cases, the model is more cost efficient and delivers a more robust performance Outlook The following measures are currently underway to improve the performance of the AI Model Hub: - Various (model specific) optimizations are rolled out on a regular basis - Improved cross-GPU load balancing (ETA July) - Adjustments to error codes (replacing HTTP 5xx with HTTP 429) to allow clients to better understand and react to situations

Jul <var data-var='date'>28</var>, <var data-var='time'>07:12</var> UTC Resolved - We are marking this incident as resolved. Our AI Modelhub Team has addressed the issue, which was caused by acute resource constraints. This was resolved by scaling out the bottlenecks. Jul <var data-var='date'>23</var>, <var data-var='time'>11:25</var> UTC Monitoring - A fix has been implemented, which has reduced the number of 4xx and 5xx responses to nominal levels. We will continue to monitoring the results. Jul <var data-var='date'>23</var>, <var data-var='time'>10:44</var> UTC Investigating - We are currently investigating increased AI Model Hub error rates and latencies. More details will be shared as they become available. Affected services: AI Model Hub Location: Global Services

Jul <var data-var='date'>27</var>, <var data-var='time'>05:43</var> UTC Resolved - Cloud Support availability is back. Thank you for your understanding. Jul <var data-var='date'>24</var>, <var data-var='time'>06:51</var> UTC Identified - While phone support will generally be available, our capacity is reduced due to multiple cases of sick leave. We want to inform you that our phone support will be limited during the following time slots, leading to increased response times on the phone channel. In these cases, please reach out per email. Thank you.

Cloud Support: Limited Phone Support Availability

Jul <var data-var='date'>25</var>, <var data-var='time'>07:49</var> UTC Resolved - No more anomalies were detected. The Root Cause of the loss of redundancy was identified as a memory leak in a management component. A durable mitigation was put in place to avoid recurrence. The memory leak will be addressed in an upcoming update to the management component. Jul <var data-var='date'>25</var>, <var data-var='time'>06:44</var> UTC Monitoring - We have found a likely root cause. A management component was causing excessive memory consumption introducing instability on the affected storage servers. This has been mitigated. We are currently monitoring the environment and will close the incident if no further anomalies are observed. Jul <var data-var='date'>25</var>, <var data-var='time'>06:27</var> UTC Investigating - We are investigating alerts related to loss of redundancy on storage servers. There is currently no customer impact, our storage team is investigating and working to restore redundancy. We are suspecting a faulty networking component.

LAS: Storage Loss of Redundancy

Jul <var data-var='date'>23</var>, <var data-var='time'>06:30</var> UTC Completed - The scheduled maintenance has been completed. Jul <var data-var='date'>23</var>, <var data-var='time'>05:30</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Jul <var data-var='date'>14</var>, <var data-var='time'>06:53</var> UTC Scheduled - We are conducting maintenance on our provisioning engine. During the maintenance customers might see delays in provisioning of up to 20 minutes — requests submitted via the Cloud API and the Data Center Designer (DCD) may take longer to process. In rare cases, provisioning errors may occur, requiring the request to be repeated. As such, we recommend scheduling provisioning tasks outside of the maintenance window where possible. All other services are expected continuing to operate normally. Availability and accessibility of your already provisioned resources will remain unaffected.

Provisioning Maintenance

Jul <var data-var='date'>22</var>, <var data-var='time'>16:00</var> UTC Completed - The scheduled maintenance has been completed. Jul <var data-var='date'>22</var>, <var data-var='time'>15:15</var> UTC In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Jul <var data-var='date'>22</var>, <var data-var='time'>15:05</var> UTC Scheduled - Please take our apologize for the short notice: We are conducting an urgent maintenance on our provisioning engine. During the maintenance, customers might see delays in provisioning of up to 20 minutes — requests submitted via the Cloud API and the Data Center Designer (DCD) may take longer to process. In rare cases, provisioning errors may occur, requiring the request to be repeated. As such, we recommend scheduling provisioning tasks outside of the maintenance window where possible. All other services are expected to operate normally. Availability and accessibility of your already provisioned resources will remain unaffected. Affected services: Activity Log API, Billing API, Cloud API, Data Center Designer (DCD), Provisioning, Reseller API Location: APIs and Frontends, Location DE/FKB, Location DE/FRA, Location DE/FRA/2, Location DE/TXL, Location ES/VIT, Location FR/PAR, Location GB/BHX, Location GB/GLO, Location GB/LHR, Location US/EWR, Location US/LAS, Location US/MCI

Is IONOS Cloud down?

IONOS Cloud status is DEGRADED

Components with issues

Lastest published events

IP Reservation Not Possible

Scheduled maintenance: Managed Kubernetes — Frankfurt (de/fra)

Cloud Support: Telephone Support reduced capacity

IONOS Cloud Services, Components and Regions

Recent IONOS Cloud events

Action Required: IONOS In-Memory DB API v1 Full Deprecation

Automated Migration to IONOS MariaDB API v2

IP Reservation Not Possible

Scheduled maintenance: Managed Kubernetes — Frankfurt (de/fra)

Cloud Support: Telephone Support reduced capacity

Disabling MariaDB Cluster Creation via API v1