Cronologia delle interruzioni di Ionos Cloud

1. 4 settembre 2026 alle ore 16:53 UTCinvestigating

   Mentre il supporto telefonico sarà generalmente disponibile, la nostra capacità è ridotta a causa di più casi di congedo di malattia. Vogliamo informarvi che il nostro supporto telefonico sarà limitato durante le scanalature del tempo seguente, portando ad aumentare i tempi di risposta sul canale del telefono. In questi casi, si prega di raggiungere per e-mail. Grazie.

2. 7 settembre 2026 alle ore 06:16 UTCidentified

   Siamo ancora a corto di copertura del servizio, e stiamo attualmente facendo modifiche sul nostro sistema di ticketing. Quindi chiediamo gentilmente la vostra comprensione se le risposte di supporto non sono così tempestive come siete abituati a. Grazie.

3. 8 settembre 2026 alle ore 06:31 UTCresolved

   Siamo riusciti a ristabilire completamente il nostro servizio, il supporto è tornato. Grazie per la vostra pazienza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 1 settembre 2026 alle ore 13:36 UTCidentified

   Per i nostri partner con subappalti: Abbiamo scoperto che i subappaltatori non possono accedere alla nuova sede di Francoforte "de/fra/1". Attualmente stiamo lavorando a una soluzione per rendere questo disponibile, Vi terremo informati quando sarà fatto.

2. 1 settembre 2026 alle ore 15:01 UTCmonitoring

   Wir konnten das Problem 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. 1 settembre 2026 alle ore 16:12 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 31 agosto 2026 alle ore 15:35 UTCinvestigating

   Il DCD non è attualmente disponibile, visualizzando una pagina senza fine "Loading DCD...". Stiamo attualmente indagando su questo problema, e vi terremo aggiornati.

2. 31 agosto 2026 alle ore 15:52 UTCmonitoring

   Il DCD è ora disponibile di nuovo, e stiamo monitorando la situazione.

3. 31 agosto 2026 alle ore 17:03 UTCresolved

   Stiamo marcando questo incidente come risolto. Il nostro team di rete sta indagando negativamente sui Servizi IAM causati da un rollout di cambiamento. Si aggiornerà la pagina di stato una volta che la causa principale è stata stabilita.

4. 1 settembre 2026 alle ore 15:32 UTCpostmortem

   Traduzione: Questo Root Cause Analysis è preliminare in quanto la ricerca è ancora in corso per determinare la causa principale tecnica dell'incidente. Che e' successo? Il 31 agosto 2026, tra le 15:00 UTC e le 15:43 ITC, e ancora tra le 16:32 UTC e le 16:35 UTC, i clienti non sono stati in grado di raggiungere il servizio Identity and Access Management di IONOS Cloud \(IAM\) e il Data Center Designer \(DCD\), che dipende da questo servizio. La perturbazione ha interessato i login diretti, l'accesso al portale partner e rivenditori e le relative console di gestione. L'impatto totale del cliente è durato circa 48 minuti in entrambi gli intervalli. Cloud APIs \([api.ionos.com](http://api.ionos.com)\) è rimasto pienamente operativo durante l'incidente. I servizi di applicazione sottostanti erano sani in ogni momento - il guasto è stato limitato allo strato bordo di rete. Come è stato possibile? ********* Durante una finestra di manutenzione programmata il 31 agosto 2026, un aggiornamento di configurazione di rete è stato applicato all'infrastruttura di rete bordo con l'intento di ottimizzare i filtri di routing. La configurazione è stata verificata come corretta prima e durante l'applicazione. Dopo il rollout, un'anomalia di propagazione del routing è emersa su un interruttore di rete di bordo, causando un comportamento asimmetrico di routing: le richieste di connessione TCP in entrata dai client sono state silenziosamente abbandonate \(black-holed\) al bordo di rete prima di raggiungere il cluster di applicazione. Poiché i servizi di applicazione stessi sono rimasti in su e sano, questa modalità di fallimento non è stato immediatamente visibile attraverso controlli sanitari interni - i servizi sono stati isolati dalla ricezione del traffico internet pubblico in entrata piuttosto che fallire. La causa principale del perché questo interruttore specifico ha mostrato il comportamento di routing asimmetrico dopo un cambiamento di configurazione altrimenti valido rimane sotto indagine attiva. Se questo è stato innescato da un comportamento della piattaforma di commutazione o da un bug specifico della versione del software viene determinato attraverso la riproduzione dell'ambiente di staging. ## ** Che cosa stiamo facendo per evitare il ripetersi? #### **Immediate Actions** Traduzione: Al momento dell'identificazione dell'anomalia di routing, un rollback completo della configurazione di rete è stato eseguito in tutti gli interruttori di bordo interessati. Gli annunci di routine e la raggiungibilità TCP degli indirizzi IP di produzione pubblica sono stati verificati dopo il rollback. Tutti i servizi interessati - DCD, Partner Portal, Reseller Portal e IAM - sono stati confermati pienamente operativi da 16:35 UTC. Traduzione: ***Staging Environment Replication:** I casi di test dettagliati vengono eseguiti nell'ambiente di staging per riprodurre l'esatto comportamento di propagazione del routing nelle stesse condizioni di configurazione dell'interruttore. L'obiettivo è quello di determinare se l'anomalia è attribuibile a un bug di versione software specifico o a un comportamento della piattaforma di commutazione, in modo che la condizione di guasto precisa può essere isolata e affrontata prima di qualsiasi futuro rollout. ETA: Entro due settimane ########Mid-term# Traduzione: Sulla base dei risultati della messa in scena, un approccio di rollout riveduto sarà progettato per garantire che qualsiasi futura applicazione di queste ottimizzazioni dei filtri di routing possa essere eseguita con maggiori garanzie di stabilità - tra cui più controlli granulari di validazione tra i cambiamenti di livello di commutazione. ETA: ottobre 2026 Traduzione: Riconosciamo che la perdita di accesso a IAM e DCD ha un impatto operativo reale. Il fatto che i servizi sottostanti erano sani durante tutto non è una mitigazione di tale impatto. Ci impegniamo a garantire che la causa principale sia pienamente compresa prima di qualsiasi ri-attrito del cambiamento originale, e che la strategia di rollout riveduta affronta le condizioni che hanno portato al comportamento di routing asimmetrico. La ringraziamo per la sua pazienza mentre concludiamo l'indagine.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 26 agosto 2026 alle ore 09:53 UTCinvestigating

   Attualmente stiamo indagando su una maggiore latenza che interessa lo storage degli oggetti S3 nella regione eu-central-1. Alcuni clienti possono sperimentare tempi di risposta lenta per le operazioni di lettura e scrittura. Il nostro team di ingegneri sta lavorando attivamente per risolvere il problema. Forniremo aggiornamenti come ulteriori informazioni diventano disponibili.

2. 27 agosto 2026 alle ore 12:00 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 31 agosto 2026 alle ore 17:08 UTCidentified

   Vediamo picchi di latenza ricorrenti che influenzano il nostro servizio S3 in eu-central-1. I team di Object Storage e Network stanno indagando insieme. Anche se una causa di radice tecnica rimane indeterminata in questo momento, la nostra massima priorità sta implementando misure per mitigare la frequenza e l'ampiezza delle punte. Apprezziamo la vostra pazienza e vi terremo informati.

4. 1 settembre 2026 alle ore 15:18 UTCidentified

   I nostri team di ingegneria hanno identificato un percorso per la bonifica. Sono state applicate misure iniziali, migliorando la situazione per alcuni servizi. I clienti che utilizzano Object Storage in eu-central-1 possono continuare a sperimentare elevata latenza, che può variare in gravità. Il lavoro continua su una soluzione completa. Forniremo ulteriori aggiornamenti

5. 3 settembre 2026 alle ore 08:27 UTCmonitoring

   I tempi di risposta per Object Storage in eu-central-1 sono migliorati in modo significativo e continuano a stabilizzarsi. Stiamo monitorando attentamente le prestazioni del sistema. Forniremo ulteriori aggiornamenti come progressi di bonifica.

6. 3 settembre 2026 alle ore 13:39 UTCresolved

   L'aumento della latenza che colpisce S3 Object Storage in eu-central-1 è stato risolto. I tempi di risposta sono tornati a livelli normali. Continueremo a monitorare il servizio.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 agosto 2026 alle ore 12:47 UTCinvestigating

   Stiamo attualmente indagando su un problema in cui Buckets e Object Storage Keys non vengono visualizzati nel Data Center Designer. Attualmente non è possibile accedere, modificare, creare ed eliminare Buckets and Keys tramite il Data Center Designer.

2. 23 agosto 2026 alle ore 17:48 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 agosto 2026 alle ore 07:52 UTCinvestigating

   Attualmente non è possibile prenotare o gestire blocchi IP, né in DCD, né tramite API. Le nostre squadre stanno indagando sul problema. Vi terremo aggiornati.

2. 21 agosto 2026 alle ore 08:18 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 23 agosto 2026 alle ore 17:49 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 agosto 2026 alle ore 14:50 UTCidentified

   Ci possono essere periodi di aumento dei tempi di attesa quando si chiama IONOS Cloud Support per telefono. Chiediamo ai Clienti e ai Partner di contattare Cloud Support tramite il modulo DCD o Email, invece.

2. 17 agosto 2026 alle ore 13:31 UTCidentified

   La situazione è ancora invariata, quindi meglio sarebbe per favore raggiungere via e-mail.

3. 20 agosto 2026 alle ore 08:18 UTCresolved

   Siamo riusciti a tornare alla normale capacità, quindi Supporto è tornato alla normale disponibilità. Grazie per la pazienza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 agosto 2026 alle ore 10:51 UTCidentified

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

2. 14 agosto 2026 alle ore 12:42 UTCmonitoring

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

3. 14 agosto 2026 alle ore 13:34 UTCresolved

   This incident has been resolved.

1. 13 agosto 2026 alle ore 00:49 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. 14 agosto 2026 alle ore 08:04 UTCresolved

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

1. 11 agosto 2026 alle ore 16:05 UTCinvestigating

   we are currently investigating increased error rate for our provisioning service.

1. 11 agosto 2026 alle ore 16:05 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. 11 agosto 2026 alle ore 16:23 UTCidentified

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

3. 11 agosto 2026 alle ore 16:37 UTCidentified

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

4. 11 agosto 2026 alle ore 19:24 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. 12 agosto 2026 alle ore 11:52 UTCresolved

   This incident has been resolved.

1. 4 agosto 2026 alle ore 10:24 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. 4 agosto 2026 alle ore 13:14 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. 4 agosto 2026 alle ore 14:37 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. 4 agosto 2026 alle ore 16:23 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. 4 agosto 2026 alle ore 21:11 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. 5 agosto 2026 alle ore 06:23 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. 5 agosto 2026 alle ore 10:07 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. 5 agosto 2026 alle ore 20:43 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. 6 agosto 2026 alle ore 08:04 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. 7 agosto 2026 alle ore 05:06 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. 10 agosto 2026 alle ore 19:58 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. 4 agosto 2026 alle ore 08:20 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. 4 agosto 2026 alle ore 10:02 UTCresolved

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

1. 28 luglio 2026 alle ore 13:46 UTCinvestigating

   Stiamo attualmente indagando su un problema di connettività che influisce sui nostri servizi DBaaS (MongoDB). Il nostro team sta lavorando per risolvere il problema, e ti aggiorneremo non appena la piena funzionalità è stata ripristinata.

2. 28 luglio 2026 alle ore 13:47 UTCinvestigating

   Stiamo continuando a indagare su questo problema.

3. 28 luglio 2026 alle ore 13:51 UTCidentified

   Abbiamo identificato un problema con DNS. Il nostro team DBaaS sta attualmente analizzando il servizio. È stato identificato un potenziale colpevole. Forniremo un altro aggiornamento qui ultime 14:15

4. 28 luglio 2026 alle ore 13:54 UTCmonitoring

   Il DBaaS Team ha eseguito un rollback di una modifica implementata prima che i servizi DNS aggiornati. Stiamo vedendo i servizi di recupero. Stiamo monitorando la situazione da vicino.

5. 28 luglio 2026 alle ore 16:36 UTCresolved

   Stiamo marcando questo incidente come risolto come non potrebbero essere rilevate ulteriori anomalie. Condivideremo un RCA non appena sarà compilato.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 25 luglio 2026 alle ore 06:27 UTCinvestigating

   Stiamo indagando sugli avvisi relativi alla perdita di ridondanza sui server di archiviazione. Attualmente non c'è alcun impatto del cliente, il nostro team di storage sta indagando e lavorando per ripristinare la ridondanza. Stiamo sospettando un componente di rete difettoso.

2. 25 luglio 2026 alle ore 06:44 UTCmonitoring

   Abbiamo trovato una probabile causa di radice. Un componente di gestione stava causando un eccessivo consumo di memoria introducendo l'instabilità sui server di archiviazione interessati. Questo è stato mitigato. Attualmente stiamo monitorando l'ambiente e chiuderemo l'incidente se non vengono osservate ulteriori anomalie.

3. 25 luglio 2026 alle ore 07:49 UTCresolved

   Non sono state rilevate più anomalie. La causa radice della perdita di ridondanza è stata identificata come una perdita di memoria in un componente di gestione. Una mitigazione duratura è stata messa in atto per evitare la ricorrenza. La perdita di memoria sarà affrontata in un prossimo aggiornamento al componente di gestione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 24 luglio 2026 alle ore 06:51 UTCidentified

   Mentre il supporto telefonico sarà generalmente disponibile, la nostra capacità è ridotta a causa di più casi di congedo di malattia. Vogliamo informarvi che il nostro supporto telefonico sarà limitato durante le scanalature del tempo seguente, portando ad aumentare i tempi di risposta sul canale del telefono. In questi casi, si prega di raggiungere per e-mail. Grazie.

2. 27 luglio 2026 alle ore 05:43 UTCresolved

   La disponibilità di Cloud Support è tornata. Grazie per la vostra comprensione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 luglio 2026 alle ore 10:44 UTCinvestigating

   Attualmente stiamo indagando sui tassi di errore AI Model Hub e sulle latenza. Più dettagli saranno condivisi come diventano disponibili. Servizi interessati: AI Model Hub Posizione: Servizi globali

2. 23 luglio 2026 alle ore 11:25 UTCmonitoring

   È stata implementata una correzione, che ha ridotto il numero di risposte 4xx e 5xx a livelli nominali. Continueremo a monitorare i risultati.

3. 28 luglio 2026 alle ore 07:12 UTCresolved

   Stiamo marcando questo incidente come risolto. Il nostro team AI Modelhub ha affrontato il problema, che è stato causato da vincoli di risorse acuti. Questo è stato risolto mettendo fuori i colli di bottiglia.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 18 luglio 2026 alle ore 13:33 UTCinvestigating

   Stiamo attualmente indagando su un problema di connettività di rete sospetta che influenza il servizio MK8s. Manterremo la pagina di stato aggiornato con le nuove informazioni che diventano disponibili.

2. 18 luglio 2026 alle ore 13:55 UTCinvestigating

   L'indagine iniziale rende improbabile un problema di connettività di rete. Il team sta concentrando l'indagine sul lato Managed Kubernetes.

3. 18 luglio 2026 alle ore 14:26 UTCidentified

   Abbiamo identificato un picco nella nostra coda del motore di provisioning che è una probabile causa principale per i problemi osservati. Il nostro team di provisioning è informato e si è unito alla risposta.

4. 18 luglio 2026 alle ore 14:47 UTCidentified

   Abbiamo ristretto il problema e crediamo di aver identificato il colpevole. Stiamo confermando il risultato.

5. 18 luglio 2026 alle ore 15:03 UTCidentified

   Il nostro team di stoccaggio ha confermato il colpevole sospettato. Attualmente stiamo mitigando il problema e monitoreremo l'esecuzione del lavoro in seguito.

6. 18 luglio 2026 alle ore 15:51 UTCidentified

   Il problema di stoccaggio è stato risolto con successo, tuttavia, il provisioning del lavoro non sta attualmente progredendo con successo. Il nostro team di provisioning sta indagando.

7. 18 luglio 2026 alle ore 16:54 UTCidentified

   Mentre il blocco di provisioning potrebbe essere risolto, stiamo indagando su un numero aumentato di errori relativi allo storage. Stiamo orientando l'attenzione su questi problemi rimanenti. I clienti potrebbero ancora vedere problemi con l'aggancio di depositi su Kubernetes.

8. 18 luglio 2026 alle ore 17:24 UTCidentified

   Abbiamo trovato un problema con un server di archiviazione appartenente a una coppia di server di archiviazione ridondante. Il nostro team sta implementando una mitigazione.

9. 18 luglio 2026 alle ore 17:54 UTCmonitoring

   L'incidente dovrebbe ora essere mitigato. Attualmente il server di archiviazione interessato viene ripristinato. Una volta completato, la ridondanza sarà completamente restaurata. Non vediamo più problemi di fornitura rimanenti. Stiamo monitorando la situazione e il restauro e poi impostare l'incidente per risolvere.

10. 18 luglio 2026 alle ore 19:27 UTCmonitoring

    A causa del continuo sforzo di ripristino sul server di archiviazione i clienti potrebbero ancora vedere l'impatto residuo quando si attacca/detaching storage fino a quando la ridondanza è completamente ripristinata. Stiamo ripristinando l'impatto del servizio di nuovo a prestazioni degradate.

11. 18 luglio 2026 alle ore 20:24 UTCmonitoring

    Il team ha incontrato una complicazione durante il recupero del secondo server di archiviazione in coppia. L'hardware deve essere sostituito. Il nostro team di datacenter sta lavorando a questo compito. Per i clienti ancora interessati stiamo lavorando per implementare una mitigazione per sbloccare le operazioni di storage in parallelo.

12. 18 luglio 2026 alle ore 21:31 UTCmonitoring

    La sostituzione dell'hardware è in corso. Il team continua a mitigare i problemi di approvvigionamento di storage acuto fino a quando la sostituzione e il recupero hardware sono completati per ridurre al minimo l'impatto del cliente.

13. 18 luglio 2026 alle ore 22:03 UTCmonitoring

    La sostituzione dell'hardware è stata completata. Restauro di ridondanza continua.

14. 18 luglio 2026 alle ore 22:43 UTCmonitoring

    La prima sostituzione hardware non ebbe successo. Un altro è tentato. Nel frattempo una migrazione dei dati è in esecuzione per migrare i dati a un altro obiettivo di archiviazione. A causa della quantità di dati da migrare la migrazione è stimata per richiedere diverse ore.

15. 19 luglio 2026 alle ore 12:21 UTCmonitoring

    La migrazione degli storage è stata completata, che dovrebbe evitare ulteriori problemi con l'aggancio di storage. La migrazione dei dati istantanei è attualmente in corso, quindi le attività relative alle snapshot potrebbero ancora non essere completate con successo.

16. 4 agosto 2026 alle ore 10:01 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.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 luglio 2026 alle ore 10:15 UTCidentified

   Mentre il supporto telefonico sarà generalmente disponibile, la nostra capacità è ridotta a causa di più casi di congedo di malattia. Vogliamo informarvi che il nostro supporto telefonico sarà limitato durante le scanalature del tempo seguente, portando ad aumentare i tempi di risposta sul canale del telefono. 15.07.2026: 21:00 – 05:00 UTC 16.07.2026: 21:00 – 05:00 UTC Se possibile, ti chiediamo di inviare i biglietti utilizzando il modulo DCD o via e-mail. Grazie per la vostra comprensione!

2. 17 luglio 2026 alle ore 16:55 UTCresolved

   La copertura del telefono è attualmente normale

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 luglio 2026 alle ore 11:18 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. 13 luglio 2026 alle ore 11:21 UTCresolved

   This was a duplicate.