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 19, 2026 - 12:21 UTC
Jul 19, 2026 - 12:21 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 18, 2026 - 22:43 UTC
Jul 18, 2026 - 22:43 UTC
Update - Hardware replacement was completed. Restoration of redundancy is continuing.
Jul 18, 2026 - 22:03 UTC
Jul 18, 2026 - 22:03 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 18, 2026 - 21:31 UTC
Jul 18, 2026 - 21:31 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 18, 2026 - 20:24 UTC
Jul 18, 2026 - 20:24 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 18, 2026 - 19:27 UTC
Jul 18, 2026 - 19:27 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 18, 2026 - 17:54 UTC
Jul 18, 2026 - 17:54 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 18, 2026 - 17:24 UTC
Jul 18, 2026 - 17:24 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 18, 2026 - 16:54 UTC
Customers could still see issues with attaching storages on Kubernetes.
Jul 18, 2026 - 16:54 UTC
Update - Storage issue has successfully been resolved, however, job provisioning is currently not progressing successfully. Our provisioning team is investigating.
Jul 18, 2026 - 15:51 UTC
Jul 18, 2026 - 15:51 UTC
Update - Our storage team has confirmed the suspected culprit. We are currently mitigating the issue and will monitor provisioning job execution afterwards.
Jul 18, 2026 - 15:03 UTC
Jul 18, 2026 - 15:03 UTC
Update - We have narrowed down the issue and believe we have the culprit identified. We are currently confirming the finding.
Jul 18, 2026 - 14:47 UTC
Jul 18, 2026 - 14:47 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 18, 2026 - 14:26 UTC
Jul 18, 2026 - 14:26 UTC
Update - Initial investigation makes a network connectivity issue unlikely. The team is focusing investigation on Managed Kubernetes side.
Jul 18, 2026 - 13:55 UTC
Jul 18, 2026 - 13:55 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.
Jul 18, 2026 - 13:33 UTC
Jul 18, 2026 - 13:33 UTC
Identified - We were able to reactivate the MK8s maintenances in all clusters in our TXL datacenter
Jun 23, 2026 - 08:21 UTC
Jun 23, 2026 - 08:21 UTC
Investigating - Due to exceptionally high demand in two clusters in our TXL and FRA datacenters, we have temporarily paused Managed Kubernetes Automated Maintenance.
To ensure that clusters remain operational without interruption during updates, Automated Maintenance requires temporary cluster "cloning", which increases resource consumption. As most maintenance windows are scheduled to run over the weekend, resource demand peaks sharply during these periods.
To protect cluster stability and prevent service degradation, we have paused maintenance for the affected clusters. Any maintenance scheduled from today onward will not run until we resume.
We know automated Kubernetes maintenance is an important feature of our platform, and we did not take this decision lightly. We are expanding capacity in the affected clusters as a high priority and will update this page as soon as maintenance resumes.
Jun 22, 2026 - 19:07 UTC
To ensure that clusters remain operational without interruption during updates, Automated Maintenance requires temporary cluster "cloning", which increases resource consumption. As most maintenance windows are scheduled to run over the weekend, resource demand peaks sharply during these periods.
To protect cluster stability and prevent service degradation, we have paused maintenance for the affected clusters. Any maintenance scheduled from today onward will not run until we resume.
We know automated Kubernetes maintenance is an important feature of our platform, and we did not take this decision lightly. We are expanding capacity in the affected clusters as a high priority and will update this page as soon as maintenance resumes.
Jun 22, 2026 - 19:07 UTC
Identified - We are currently experiencing exceptionally high demand for GPU servers, which has temporarily limited our available capacity. As a result, you may encounter provisioning errors when attempting to create a new GPU server or start an existing one.
What You Can Do
- Try again later: We cannot provide an exact timeline for when capacity will be added. However, we are monitoring the situation closely and will update this status page once substantial free capacity becomes available.
- Provision a smaller GPU server: Because availability fluctuates rapidly, we cannot guarantee which specific sizes are currently open. Attempting to provision a smaller instance may increase your chances of success.
- If you currently have a provisioned and running GPU server, do not shut it down. Due to the low supply, freed resources may be immediately allocated to other customers, and you will likely be unable to restart your server.
Next Steps & Resolution
Resolving this resource constraint has high priority. Our teams are working to increase capacity to meet demand as quickly as possible.
We sincerely appreciate your patience and understanding.
Jun 18, 2026 - 15:04 UTC
What You Can Do
- Try again later: We cannot provide an exact timeline for when capacity will be added. However, we are monitoring the situation closely and will update this status page once substantial free capacity becomes available.
- Provision a smaller GPU server: Because availability fluctuates rapidly, we cannot guarantee which specific sizes are currently open. Attempting to provision a smaller instance may increase your chances of success.
- If you currently have a provisioned and running GPU server, do not shut it down. Due to the low supply, freed resources may be immediately allocated to other customers, and you will likely be unable to restart your server.
Next Steps & Resolution
Resolving this resource constraint has high priority. Our teams are working to increase capacity to meet demand as quickly as possible.
We sincerely appreciate your patience and understanding.
Jun 18, 2026 - 15:04 UTC
Investigating - MongoDB Playground and Business Edition clusters are currently not available for provisioning in de/fra/2 (Frankfurt East). This is due to a capacity limitation in that location that prevents these cluster types from being created reliably, and it is expected to persist for the time being. We will update this status page as soon as this limitation is lifted.
As an alternative, you can:
- Provision your Playground or Business Edition cluster in another available location, or
- Use MongoDB Enterprise Edition, which remains available in Frankfurt East.
Jun 12, 2026 - 15:46 UTC
As an alternative, you can:
- Provision your Playground or Business Edition cluster in another available location, or
- Use MongoDB Enterprise Edition, which remains available in Frankfurt East.
Jun 12, 2026 - 15:46 UTC
Cloud Support
Operational
Location DE/FKB
Operational
Compute
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Private Cloud
Operational
Logging Service
Operational
Monitoring Service
Operational
Location DE/FRA
Operational
Compute
Operational
Cubes
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Object Storage
Operational
Logging Service
Operational
Monitoring Service
Operational
Location DE/FRA/2
Operational
Compute
Operational
Cubes
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Object Storage
Operational
Logging Service
Operational
Monitoring Service
Operational
Location DE/TXL
Degraded Performance
Compute
Operational
Cubes
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Degraded Performance
Supporting Services
Operational
Provisioning
Operational
Object Storage
Operational
Private Cloud
Operational
Logging Service
Operational
Monitoring Service
Operational
Location ES/VIT
Operational
Compute
Operational
Cubes
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Object Storage
Operational
Logging Service
Operational
Monitoring Service
Operational
Location FR/PAR
Operational
Compute
Operational
Storage
Operational
Cubes
Operational
Managed Kubernetes
Operational
Provisioning
Operational
Supporting Services
Operational
Network
Operational
Logging Service
Operational
Monitoring Service
Operational
Location GB/BHX
Operational
Compute
Operational
Cubes
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Logging Service
Operational
Monitoring Service
Operational
Location GB/GLO
Operational
Private Cloud
Operational
Location GB/LHR
Operational
Compute
Operational
Cubes
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Logging Service
Operational
Monitoring Service
Operational
Location US/EWR
Operational
Compute
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Logging Service
Operational
Monitoring Service
Operational
Location US/LAS
Operational
Compute
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Supporting Services
Operational
Provisioning
Operational
Logging Service
Operational
Monitoring Service
Operational
Location US/MCI
Operational
Compute
Operational
Storage
Operational
Network
Operational
Managed Kubernetes
Operational
Provisioning
Operational
Supporting Services
Operational
Logging Service
Operational
Monitoring Service
Operational
APIs and Frontends
Operational
Data Center Designer (DCD)
Operational
Cloud API
Operational
Billing API
Operational
Reseller API
Operational
Activity Log API
Operational
Global Services
Operational
Backup Service
Operational
CloudDNS
Operational
Database as a Service (DBaaS)
Operational
Monitoring as a Service (MaaS)
Operational
Content Delivery Network (CDN)
Operational
AI Model Hub
Operational
IAM
Operational
Container Registry
Operational
Accounts and Billing
Operational
GPU Server
Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Scheduled Maintenance
Automated DBaaS PostgreSQL v1 to v2 Infrastructure Migration Aug 3, 2026 09:00 - Aug 6, 2026 17:00 UTC
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
Posted on Jul 16, 2026 - 13:34 UTC
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
Posted on Jul 16, 2026 - 13:34 UTC
Disabling In-Memory DB Cluster Creation via API v1 Aug 3, 2026 10:00-14:00 UTC
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
Posted on Jul 23, 2026 - 13:33 UTC
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
Posted on Jul 23, 2026 - 13:33 UTC