Historial de interrupciones de Ionos Cloud

1. September 4, 2026 at 4:53 PM UTCinvestigating

   Mientras que el soporte telefónico generalmente estará disponible, nuestra capacidad se reduce debido a múltiples casos de licencia por enfermedad. Queremos informarle de que nuestro soporte telefónico estará limitado durante las ranuras de tiempo siguientes, lo que dará lugar a un aumento de los tiempos de respuesta en el canal telefónico. En estos casos, por favor contacte por correo electrónico. Gracias.

2. September 7, 2026 at 6:16 AM UTCidentified

   Todavía no tenemos cobertura de servicio, y estamos haciendo cambios en nuestro sistema de tickets. Así que amablemente pedimos su comprensión si las respuestas de Soporte no son tan oportunas como usted está acostumbrado. Gracias.

Traducido automáticamente desde la actualización oficial del incidente.

1. September 1, 2026 at 1:36 PM UTCidentified

   Para nuestros socios con subcontratos: Encontramos que los subcontratos no pueden acceder a la nueva ubicación de Frankfurt "de/fra/1". Actualmente estamos trabajando en una solución para hacer esto disponible, te mantendremos informado cuando esté hecho.

2. September 1, 2026 at 3:01 PM UTCmonitoring

   Wir konnten das Problema beheben, sodass die neue Region nun für alle Verträge verfügbar ist. Wir monitoren, ob es dazu noch weitere Rückmeldungen gibt.

3. September 1, 2026 at 4:12 PM UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. August 31, 2026 at 3:35 PM UTCinvestigating

   El DCD es actualmente indisponible, mostrando una interminable página de "Loading DCD...". Actualmente estamos investigando este problema, y lo mantendremos actualizado.

2. August 31, 2026 at 3:52 PM UTCmonitoring

   El DCD está disponible de nuevo, y estamos monitoreando la situación.

3. August 31, 2026 at 5:03 PM UTCresolved

   Estamos marcando este incidente como resuelto. Nuestro equipo de red está investigando impacto negativo en los Servicios IAM causados por un cambio de despliegue. Actualizaremos la página de estado una vez que se haya establecido la causa raíz.

4. September 1, 2026 at 3:32 PM UTCpostmortem

   # Preliminary Root Cause Analysis # Este análisis de la causa raíz es preliminar ya que la investigación todavía se está llevando a cabo para determinar la causa raíz técnica del incidente. ¿Qué pasó? El 31 de agosto de 2026, entre las 15:00 UTC y 15:43 ITC, y de nuevo entre 16:32 UTC y 16:35 UTC, los clientes no pudieron alcanzar el servicio IONOS Cloud de Identidad y Gestión de Accesos \(IAM\) y el diseñador del Centro de Datos \(DCD\), que depende de este servicio. La perturbación afectó a los accesos directos, el acceso a los portales de socios y revendedores, y las consolas de gestión asociadas. El impacto total del cliente duró aproximadamente 48 minutos a través de ambos intervalos. Las API de la nube \([api.ionos.com](http://api.ionos.com)\) permanecieron plenamente operativas durante todo el incidente. Los servicios de aplicación subyacentes eran saludables en todo momento - el fracaso se limitaba a la capa de borde de red. ## **¿Cómo fue posible? \(Root Cause\)** Durante una ventana de mantenimiento programada el 31 de agosto de 2026, se aplicó una actualización de configuración de la red de bordes con la intención de optimizar los filtros de enrutamiento. La configuración fue verificada como correcta antes y durante la aplicación. Después de la puesta en marcha, una anomalía de propagación de enrutamiento surgió en un interruptor de red de bordes, causando comportamiento asimétrico de enrutamiento: las solicitudes de conexión TCP entrantes de los clientes se retiraron silenciosamente \(holed negro\) en el borde de red antes de llegar al cluster de aplicación. Debido a que los servicios de aplicación se mantuvieron en sí mismos y saludables, este modo de falla no fue inmediatamente visible a través de controles internos de salud - los servicios fueron aislados de recibir tráfico de Internet público inbound en lugar de fallar. La causa raíz de por qué este interruptor específico exhibió comportamiento de enrutamiento asimétrico después de un cambio de configuración válido de otro modo permanece bajo investigación activa. Si esto fue desencadenado por un comportamiento de la plataforma de conmutación o un error de versión de software específico está siendo determinado a través de la reproducción del entorno de estancamiento. ## ** ¿Qué estamos haciendo para prevenir la recurrencia?** #### ** Acciones inmediatas** * **Configuration Rollback:** Al identificar la anomalía de enrutamiento, se ejecutó una versión completa de la configuración de red en todos los interruptores de borde afectados. Los anuncios de rutina y la accesibilidad TCP de las direcciones IP de producción pública fueron verificados después de la devolución. Todos los servicios afectados - DCD, Partner Portal, Reseller Portal e IAM - fueron confirmados totalmente operativos por 16:35 UTC. \(DONE\) #### **Short-term** * **Staging Environment Replication:** Se están ejecutando casos de prueba detallados en el entorno de estadificación para reproducir el comportamiento exacto de propagación de enrutamiento bajo las mismas condiciones de configuración de conmutación. El objetivo es determinar si la anomalía es atribuible a un fallo de versión de software específico o a un comportamiento de la plataforma de conmutación, de modo que la condición de fallo preciso pueda ser aislada y abordada antes de cualquier futura puesta en marcha. ETA: Dentro de dos semanas #### **Mid-term** * ** Estrategia Revise Rollout:** Sobre la base de los hallazgos de la puesta en escena, se diseñará un enfoque revisado para asegurar que cualquier aplicación futura de estas optimizaciones de filtros de enrutamiento pueda realizarse con mayores garantías de estabilidad, incluyendo puntos de validación más granular entre cambios de nivel de conmutación. ETA: octubre 2026 ## **Closing remarks** Reconocemos que la pérdida de acceso al IAM y al DCD conlleva un impacto operacional real. El hecho de que los servicios subyacentes fueran saludables no es una mitigación de ese impacto. Nos comprometemos a asegurar que la causa raíz sea plenamente comprendida antes de cualquier intento de cambio original, y que la estrategia de despliegue revisada aborde las condiciones que llevaron a la conducta de enrutamiento asimétrico. Le agradecemos su paciencia mientras concluimos la investigación.

Traducido automáticamente desde la actualización oficial del incidente.

1. August 26, 2026 at 9:53 AM UTCinvestigating

   Actualmente estamos investigando un aumento de latencia que afecta al almacenamiento de objetos S3 en la región eu-central-1. Algunos clientes pueden experimentar tiempos de respuesta lentos para operaciones de lectura y escritura. Nuestro equipo de ingeniería está trabajando activamente para resolver el problema. Proporcionaremos actualizaciones a medida que se disponga de más información.

2. August 27, 2026 at 12:00 PM UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. August 31, 2026 at 5:08 PM UTCidentified

   Vemos puntos de latencia recurrentes que afectan nuestro servicio S3 en eu-central-1. Los equipos de almacenamiento y red de objetos están investigando conjuntamente. Aunque la causa de raíz técnica sigue siendo indeterminada en este momento, nuestra máxima prioridad es la aplicación de medidas para mitigar la frecuencia y amplitud de los picos. Apreciamos su paciencia y le mantendremos informado.

4. September 1, 2026 at 3:18 PM UTCidentified

   Nuestros equipos de ingeniería han identificado un camino hacia la rehabilitación. Se han aplicado medidas iniciales, mejorando la situación de algunos servicios. Los clientes que utilizan el almacenamiento de objetos en eu-central-1 pueden seguir experimentando latencia elevada, que puede variar en gravedad. El trabajo continúa con una solución integral. Vamos a proporcionar nuevas actualizaciones

5. September 3, 2026 at 8:27 AM UTCmonitoring

   Los tiempos de respuesta para el almacenamiento de objetos en eu-central-1 han mejorado significativamente y siguen estabilizando. Estamos monitoreando de cerca el rendimiento del sistema. Proporcionaremos nuevas actualizaciones a medida que avance la rehabilitación.

6. September 3, 2026 at 1:39 PM UTCresolved

   Se ha resuelto el aumento de latencia que afecta al almacenamiento de objetos S3 en eu-central-1. Los tiempos de respuesta han vuelto a niveles normales. Seguiremos vigilando el servicio.

Traducido automáticamente desde la actualización oficial del incidente.

1. August 23, 2026 at 12:47 PM UTCinvestigating

   Actualmente estamos investigando un problema en el que las claves de almacenamiento de cubos y objetos no se muestran en el diseñador del centro de datos. Actualmente no es posible acceder, alterar, crear y eliminar Buckets y Keys a través del Data Center Designer.

2. August 23, 2026 at 5:48 PM UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. August 21, 2026 at 7:52 AM UTCinvestigating

   Actualmente no es posible reservar o manejar bloques IP, ni en DCD, ni a través de API. Nuestros equipos están investigando el tema. Te mantendremos actualizado.

2. August 21, 2026 at 8:18 AM UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. August 23, 2026 at 5:49 PM UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. August 14, 2026 at 2:50 PM UTCidentified

   Puede haber períodos de tiempo de espera aumentado al llamar a IONOS Cloud Support por teléfono. Pedimos a los clientes y socios que se pongan en contacto con Cloud Support a través del formulario DCD o el correo electrónico.

2. August 17, 2026 at 1:31 PM UTCidentified

   La situación sigue sin cambiar, por lo que lo mejor sería llegar por correo electrónico.

3. August 20, 2026 at 8:18 AM UTCresolved

   Nos las arreglamos para volver a la capacidad normal, así que el soporte está de vuelta a la disponibilidad normal. Gracias por la paciencia.

Traducido automáticamente desde la actualización oficial del incidente.

1. August 14, 2026 at 10:51 AM UTCidentified

   We are currently reports of error VDC-14-1836 during provisioning operations. Our provisioning team is informed and is preparing a hotfix.

2. August 14, 2026 at 12:42 PM UTCmonitoring

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

3. August 14, 2026 at 1:34 PM UTCresolved

   This incident has been resolved.

1. August 13, 2026 at 12:49 AM UTCinvestigating

   We are currently investigating reports of increased AI Model Hub error rates and latencies. More details will be shared as they become available.

2. August 14, 2026 at 8:04 AM UTCresolved

   We were able to resolve this issue, it's back to normal now.

1. August 11, 2026 at 4:05 PM UTCinvestigating

   actualmente estamos investigando un aumento de la tasa de error para nuestro servicio de provisión.

Traducido automáticamente desde la actualización oficial del incidente.

1. August 11, 2026 at 4:05 PM UTCinvestigating

   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.

2. August 11, 2026 at 4:23 PM UTCidentified

   We have identified a likely culprit. The Provisioning Team has implemented a mitigation. We see the performance of the service stabilizing.

3. August 11, 2026 at 4:37 PM UTCidentified

   We are still seeing residual 500 errors from the Cloud API and are working towards resolving the remaining service degradation.

4. August 11, 2026 at 7:24 PM UTCmonitoring

   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.

5. August 12, 2026 at 11:52 AM UTCresolved

   This incident has been resolved.

1. August 4, 2026 at 10:24 AM UTCidentified

   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.

2. August 4, 2026 at 1:14 PM UTCidentified

   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.

3. August 4, 2026 at 2:37 PM UTCidentified

   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.

4. August 4, 2026 at 4:23 PM UTCidentified

   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.

5. August 4, 2026 at 9:11 PM UTCmonitoring

   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.

6. August 5, 2026 at 6:23 AM UTCidentified

   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.

7. August 5, 2026 at 10:07 AM UTCidentified

   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.

8. August 5, 2026 at 8:43 PM UTCidentified

   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.

9. August 6, 2026 at 8:04 AM UTCmonitoring

   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.

10. August 7, 2026 at 5:06 AM UTCmonitoring

    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.

11. August 10, 2026 at 7:58 PM UTCresolved

    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

1. August 4, 2026 at 8:20 AM UTCidentified

   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.

2. August 4, 2026 at 10:02 AM UTCresolved

   We were able to assign additional personnel and will set this status page to resolved.

1. July 28, 2026 at 1:46 PM UTCinvestigating

   Actualmente estamos investigando un problema de conectividad que impacta nuestros servicios de DBaaS (MongoDB). Nuestro equipo está trabajando para resolver el problema, y le actualizaremos tan pronto como se haya restaurado toda la funcionalidad.

2. July 28, 2026 at 1:47 PM UTCinvestigating

   Seguimos investigando esta cuestión.

3. July 28, 2026 at 1:51 PM UTCidentified

   Hemos identificado un problema con DNS. Nuestro equipo de DBaaS está analizando el servicio. Se ha identificado un posible culpable. Vamos a proporcionar otra actualización aquí las últimas 14:15

4. July 28, 2026 at 1:54 PM UTCmonitoring

   El equipo de DBaaS ha realizado un retroceso de un cambio desplegado antes de actualizar los servicios de DNS. Estamos viendo servicios recuperando. Estamos monitoreando la situación de cerca.

5. July 28, 2026 at 4:36 PM UTCresolved

   Estamos marcando este incidente tan resuelto como no se pueden detectar otras anomalías. Compartiremos un RCA tan pronto como sea compilado.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 25, 2026 at 6:27 AM UTCinvestigating

   Estamos investigando alertas relacionadas con la pérdida de redundancia en servidores de almacenamiento. Actualmente no hay ningún impacto del cliente, nuestro equipo de almacenamiento está investigando y trabajando para restaurar la redundancia. Sospechamos un componente de networking defectuoso.

2. July 25, 2026 at 6:44 AM UTCmonitoring

   Hemos encontrado una causa raíz probable. Un componente de gestión estaba causando un excesivo consumo de memoria introduciendo inestabilidad en los servidores de almacenamiento afectados. Esto ha sido mitigado. Actualmente estamos monitoreando el medio ambiente y cerraremos el incidente si no se observan más anomalías.

3. July 25, 2026 at 7:49 AM UTCresolved

   No se detectaron más anomalías. La causa raíz de la pérdida de redundancia se identificó como una fuga de memoria en un componente de gestión. Se puso en marcha una mitigación duradera para evitar la recurrencia. La fuga de memoria se abordará en una próxima actualización al componente de gestión.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 24, 2026 at 6:51 AM UTCidentified

   Mientras que el soporte telefónico generalmente estará disponible, nuestra capacidad se reduce debido a múltiples casos de licencia por enfermedad. Queremos informarle de que nuestro soporte telefónico estará limitado durante las ranuras de tiempo siguientes, lo que dará lugar a un aumento de los tiempos de respuesta en el canal telefónico. En estos casos, por favor contacte por correo electrónico. Gracias.

2. July 27, 2026 at 5:43 AM UTCresolved

   La disponibilidad de Cloud Support está de vuelta. Gracias por su comprensión.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 23, 2026 at 10:44 AM UTCinvestigating

   Actualmente estamos investigando mayores tasas de error y retrasos de AI Model Hub. Se compartirán más detalles cuando estén disponibles. Servicios afectados: Centro modelo AI Ubicación: Servicios Globales

2. July 23, 2026 at 11:25 AM UTCmonitoring

   Se ha aplicado una solución, que ha reducido el número de respuestas 4x y 5xx a niveles nominales. Seguiremos monitoreando los resultados.

3. July 28, 2026 at 7:12 AM UTCresolved

   Estamos marcando este incidente como resuelto. Nuestro equipo de modelos AI ha abordado la cuestión, causada por graves limitaciones de recursos. Esto se resolvió al sacar los cuellos de botella.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 18, 2026 at 1:33 PM UTCinvestigating

   Actualmente estamos investigando un problema de conectividad de red sospechoso que influye en el servicio MK8s. Mantendremos la página de estado actualizada con nueva información cuando estén disponibles.

2. July 18, 2026 at 1:55 PM UTCinvestigating

   La investigación inicial hace improbable un problema de conectividad de red. El equipo está centrando la investigación en Managed Kubernetes side.

3. July 18, 2026 at 2:26 PM UTCidentified

   Hemos identificado un aumento en nuestra cola de motor que es una causa probable de raíz para los problemas observados. Nuestro equipo de suministro está informado y se ha unido a la respuesta.

4. July 18, 2026 at 2:47 PM UTCidentified

   Hemos reducido la cuestión y creemos que hemos identificado al culpable. Actualmente estamos confirmando el hallazgo.

5. July 18, 2026 at 3:03 PM UTCidentified

   Nuestro equipo de almacenamiento ha confirmado al culpable sospechoso. Actualmente estamos atenuando la cuestión y monitoreando la ejecución de empleo después.

6. July 18, 2026 at 3:51 PM UTCidentified

   Sin embargo, la cuestión del almacenamiento se ha resuelto con éxito, la provisión de empleo no está progresando con éxito. Nuestro equipo de provisiones está investigando.

7. July 18, 2026 at 4:54 PM UTCidentified

   Mientras que el bloque de suministro podría resolverse, estamos investigando un mayor número de errores relacionados con el almacenamiento. Estamos dirigiendo la atención a estas cuestiones pendientes. Los clientes todavía podían ver problemas con la fijación de almacenamientos en Kubernetes.

8. July 18, 2026 at 5:24 PM UTCidentified

   Hemos encontrado un problema con un servidor de almacenamiento perteneciente a un par de servidor de almacenamiento redundante. Nuestro equipo está implementando una mitigación.

9. July 18, 2026 at 5:54 PM UTCmonitoring

   El incidente debería mitigarse ahora. El servidor de almacenamiento afectado está siendo restaurado. Una vez que esto termine, la redundancia será totalmente restaurada. Ya no vemos ningún problema de provisión restante. Estamos monitoreando la situación y la restauración y luego estableceremos el incidente para resolver.

10. July 18, 2026 at 7:27 PM UTCmonitoring

    Debido al esfuerzo de restauración en curso en los clientes del servidor de almacenamiento podría todavía ver impacto residual al adjuntar / desvincular almacenamiento hasta que se restablezca la redundancia completamente. Estamos reajustando el impacto del servicio de vuelta a Desgradado rendimiento.

11. July 18, 2026 at 8:24 PM UTCmonitoring

    El equipo ha encontrado una complicación durante la recuperación del segundo servidor de almacenamiento en el par. Hardware necesita ser reemplazado. Nuestro equipo de centro de datos está trabajando en esta tarea. Para los clientes todavía afectados estamos trabajando en la implementación de una mitigación para desbloquear operaciones de almacenamiento en paralelo.

12. July 18, 2026 at 9:31 PM UTCmonitoring

    Se está realizando un reemplazo de hardware. El equipo sigue atenuando los problemas de almacenamiento agudo hasta que se complete la sustitución de hardware y la recuperación para reducir al mínimo el impacto del cliente.

13. July 18, 2026 at 10:03 PM UTCmonitoring

    Se completó el reemplazo de hardware. Continúa la restauración de la redundancia.

14. July 18, 2026 at 10:43 PM UTCmonitoring

    El primer reemplazo de hardware no tuvo éxito. Otro es intentado. Mientras tanto, una migración de datos se está ejecutando para migrar datos a otro objetivo de almacenamiento. Debido a la cantidad de datos que se migraron, se estima que la migración tarda varias horas.

15. July 19, 2026 at 12:21 PM UTCmonitoring

    Se ha completado la migración de los almacenamientos, lo que debería impedir nuevas cuestiones con el almacenamiento. La migración de datos de instantáneas está actualmente en curso, por lo que las actividades relacionadas con instantáneas podrían no completarse con éxito.

16. August 4, 2026 at 10:01 AM UTCresolved

    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.

Traducido automáticamente desde la actualización oficial del incidente.

1. July 15, 2026 at 10:15 AM UTCidentified

   Mientras que el soporte telefónico generalmente estará disponible, nuestra capacidad se reduce debido a múltiples casos de licencia por enfermedad. Queremos informarle de que nuestro soporte telefónico estará limitado durante las ranuras de tiempo siguientes, lo que dará lugar a un aumento de los tiempos de respuesta en el canal telefónico. 15.07.2026: 21:00 – 05:00 UTC 16.07.2026: 21:00 – 05:00 UTC Si es posible, le pedimos que envíe entradas usando el formulario DCD o por correo electrónico. ¡Gracias por su comprensión!

2. July 17, 2026 at 4:55 PM UTCresolved

   La cobertura del teléfono es normal

Traducido automáticamente desde la actualización oficial del incidente.

1. July 13, 2026 at 11:18 AM UTCinvestigating

   We are currently investigating problems accessing VMs and DBaaS service located in Frankfurt. We will inform you as soon as the functionality has been restored.

2. July 13, 2026 at 11:21 AM UTCresolved

   This was a duplicate.