Historique des pannes de Ionos Cloud

1. 4 septembre 2026 à 16:53 UTCinvestigating

   Bien que le soutien téléphonique soit généralement disponible, notre capacité est réduite en raison de plusieurs cas de congé de maladie. Nous voulons vous informer que notre support téléphonique sera limité pendant les intervalles de temps suivants, ce qui entraînera des temps de réponse accrus sur le canal téléphonique. Dans ces cas, veuillez contacter par courriel. Je vous remercie.

2. 7 septembre 2026 à 06:16 UTCidentified

   Nous manquons encore de couverture du service, et nous sommes en train de modifier notre système de billetterie. Nous vous demandons donc de bien vouloir comprendre si les réponses de l'aide ne sont pas aussi opportunes que vous en avez l'habitude. Je vous remercie.

3. 8 septembre 2026 à 06:31 UTCresolved

   Nous avons réussi à rétablir pleinement notre service, Support est de retour. Merci pour votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 septembre 2026 à 13:36 UTCidentified

   Pour nos partenaires de sous-traitance : Nous avons constaté que les contrats de sous-traitance ne peuvent pas accéder au nouvel emplacement de Francfort "de/fra/1". Nous travaillons actuellement sur un correctif pour rendre cela disponible, Nous vous tiendrons au courant.

2. 1 septembre 2026 à 15:01 UTCmonitoring

   Wir konnten das Problème beheben, sodass die neue Région nun für alle Verträge verfügbar ist. Moniteur Wir, ob es dazu noch weitere Rückmeldungen gibt.

3. 1 septembre 2026 à 16:12 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 15:35 UTCinvestigating

   Le DCD n'est actuellement pas disponible, affichant une page sans fin "Loading DCD...". Nous enquêtons actuellement sur cette question et vous tenir à jour.

2. 31 août 2026 à 15:52 UTCmonitoring

   Le DCD est à nouveau disponible et nous suivons la situation.

3. 31 août 2026 à 17:03 UTCresolved

   Nous marquons cet incident comme résolu. Notre équipe réseau enquête sur l'impact négatif sur les services IAM causé par un déploiement de changement. Nous mettrons à jour la page de statut une fois que la cause profonde aura été établie.

4. 1 septembre 2026 à 15:32 UTCpostmortem

   # **Analyse préliminaire des causes des racines** Cette analyse de la cause fondamentale est préliminaire puisque des recherches sont toujours en cours pour déterminer la cause fondamentale technique de l'incident. Que s'est-il passé ? Le 31 août 2026, entre 15:00 UTC et 15:43 CCI, et encore entre 16:32 UTC et 16:35 UTC, les clients n'ont pas pu atteindre le service Identity and Access Management \(IAM\) d'IONOS Cloud et le Data Center Designer \(DCD\), qui dépend de ce service. La perturbation a affecté les connexions directes, l'accès au portail des partenaires et des revendeurs et les consoles de gestion associées. L'impact total face au client a duré environ 48 minutes sur les deux intervalles. Les API Cloud \([api.ionos.com](http://api.ionos.com) sont restées pleinement opérationnelles tout au long de l'incident. Les services d'application sous-jacents étaient en tout temps sains - la défaillance était limitée à la couche de bord du réseau. Comment c'était possible ? \(Frais de roulement\)** Au cours d'une fenêtre de maintenance prévue le 31 août 2026, une mise à jour de la configuration du réseau a été appliquée à l'infrastructure du réseau périphérique dans le but d'optimiser les filtres de routage. La configuration a été vérifiée comme correcte avant et pendant l'application. Après le déploiement, une anomalie de propagation de routage est apparue sur un interrupteur réseau de bord, provoquant un comportement de routage asymétrique : les requêtes de connexion TCP entrantes des clients ont été silencieusement abandonnées \(black-holed\) au bord du réseau avant d'atteindre le cluster d'application. Étant donné que les services d'application eux-mêmes sont demeurés en bonne santé, ce mode de défaillance n'était pas immédiatement visible par des contrôles de santé internes - les services ont été isolés de la réception du trafic Internet public entrant plutôt que d'échouer. La cause principale de ce commutateur spécifique a montré un comportement de routage asymétrique suite à un changement de configuration par ailleurs valide reste sous enquête active. Que cela ait été déclenché par un comportement de plate-forme de commutation ou par un bug spécifique à la version du logiciel est déterminé par la reproduction d'environnement de mise en scène. **Qu'est-ce qu'on fait pour éviter les récidives?** Actions immédiates * **Rouleau de configuration :** Lors de l'identification de l'anomalie de routage, un retour complet de la configuration réseau a été exécuté sur tous les commutateurs de bord touchés. Les annonces d'acheminement et l'accessibilité TCP des adresses IP de production publique ont été vérifiées après le renversement. Tous les services touchés - DCD, Portail partenaire, Portail revendeur et IAM - ont été confirmés pleinement opérationnels par 16h35 UTC. \(DONE\) ** court terme** * **Réplication de l'environnement de localisation :** Des cas de test détaillés sont exécutés dans l'environnement de mise en scène pour reproduire le comportement de propagation du routage exact dans les mêmes conditions de configuration du commutateur. L'objectif est de déterminer si l'anomalie est attribuable à un bug de version de logiciel spécifique ou à un comportement de plate-forme de commutation, de sorte que la condition de défaillance précise peut être isolée et traitée avant tout déploiement futur. ETA: Dans les deux semaines **Moyenne** * **Stratégie révisée de déploiement:** Sur la base des résultats de la mise en place, une approche de déploiement révisée sera conçue pour garantir que toute application future de ces optimisations du filtre de routage puisse être effectuée avec de plus grandes garanties de stabilité - y compris des points de contrôle plus granulaires entre les changements de niveau de commutation. ETA: octobre 2026 ** Remarques manquantes** Nous reconnaissons que la perte d'accès à l'IAM et au DCD a un impact opérationnel réel. Le fait que les services sous-jacents aient été en bonne santé tout au long de la vie n'est pas une atténuation de cet impact. Nous nous engageons à faire en sorte que la cause profonde soit pleinement comprise avant toute ré-attaque du changement initial, et que la stratégie de déploiement révisée réponde aux conditions qui ont conduit au comportement de routage asymétrique. Nous vous remercions de votre patience pendant que nous concluons l'enquête.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 26 août 2026 à 09:53 UTCinvestigating

   Nous enquêtons actuellement sur une augmentation de la latence affectant le stockage d'objets S3 dans la région eu-central-1. Certains clients peuvent éprouver des temps de réponse lents pour lire et écrire des opérations. Notre équipe d'ingénieurs travaille activement à résoudre le problème. Nous fournirons des mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 27 août 2026 à 12:00 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 31 août 2026 à 17:08 UTCidentified

   Nous voyons des pics de latence récurrents affectant notre service S3 dans eu-central-1. Les équipes de stockage d'objets et de réseau enquêtent conjointement. Bien qu'une cause fondamentale technique reste indéterminée à l'heure actuelle, notre priorité absolue est de mettre en oeuvre des mesures visant à atténuer la fréquence et l'amplitude des pics. Nous apprécions votre patience et vous tiendra informés.

4. 1 septembre 2026 à 15:18 UTCidentified

   Nos équipes d'ingénierie ont identifié un chemin vers l'assainissement. Des mesures initiales ont été appliquées pour améliorer la situation de certains services. Les clients utilisant Object Storage dans eu-central-1 peuvent continuer à éprouver une latence élevée, qui peut varier en gravité. Les travaux se poursuivent sur une solution globale. Nous fournirons d'autres mises à jour

5. 3 septembre 2026 à 08:27 UTCmonitoring

   Les temps de réponse pour le stockage d'objets dans eu-central-1 se sont considérablement améliorés et continuent de se stabiliser. Nous surveillons de près la performance du système. Nous fournirons d'autres mises à jour à mesure que l'assainissement progressera.

6. 3 septembre 2026 à 13:39 UTCresolved

   La latence accrue affectant le stockage d'objets S3 dans eu-central-1 a été résolue. Les temps de réponse sont revenus à des niveaux normaux. Nous continuerons de surveiller le service.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 août 2026 à 12:47 UTCinvestigating

   Nous enquêtons actuellement sur un problème où Buckets et Object Storage Keys ne sont pas affichés dans le Data Center Designer. Il n'est actuellement pas possible d'accéder, de modifier, de créer et de supprimer des Buckets et des Clés via le Data Center Designer.

2. 23 août 2026 à 17:48 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 août 2026 à 07:52 UTCinvestigating

   Actuellement, il n'est pas possible de réserver ou de gérer des blocs IP, ni dans DCD, ni via API. Nos équipes enquêtent sur le problème. Nous vous tiendrons au courant.

2. 21 août 2026 à 08:18 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 23 août 2026 à 17:49 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 août 2026 à 14:50 UTCidentified

   Il peut y avoir des périodes de temps d'attente augmenté lorsque vous appelez IONOS Cloud Support par téléphone. Nous demandons aux clients et partenaires de contacter Cloud Support via le formulaire DCD ou Email, à la place.

2. 17 août 2026 à 13:31 UTCidentified

   La situation est toujours inchangée, donc le mieux serait de s'adresser par courriel.

3. 20 août 2026 à 08:18 UTCresolved

   Nous avons réussi à revenir à la capacité normale, donc le support est de retour à la disponibilité normale. Merci pour la patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 14 août 2026 à 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 août 2026 à 12:42 UTCmonitoring

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

3. 14 août 2026 à 13:34 UTCresolved

   This incident has been resolved.

1. 13 août 2026 à 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 août 2026 à 08:04 UTCresolved

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

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 11 août 2026 à 16:05 UTCinvestigating

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

1. 11 août 2026 à 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 août 2026 à 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 août 2026 à 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 août 2026 à 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 août 2026 à 11:52 UTCresolved

   This incident has been resolved.

1. 4 août 2026 à 10:24 UTCidentified

   Nous sommes conscients de l'indisponibilité intermittente d'un plan de contrôle affectant un sous-ensemble de clients de Kubernetes gérés. Les clients touchés peuvent subir des pannes d'appels API, des délais de déploiement et des perturbations temporaires des opérations de gestion des grappes. Notre équipe d'ingénierie travaille activement à la fois sur les mesures d'atténuation immédiates et sur les améliorations architecturales à long terme. Plusieurs mesures d'atténuation ont déjà été prises, notamment l'optimisation du calendrier de maintenance, les correctifs de régression du compactage et les améliorations des performances de stockage. D'autres mesures - notamment la migration des infrastructures, les regroupements d'événements spécialisés, l'amélioration de l'équilibre des charges et l'échelle horizontale - sont en cours. Nous fournissons des mises à jour régulières sur cette page. Les clients qui éprouvent des problèmes sont encouragés à s'abonner à cet incident pour recevoir des notifications en temps opportun.

2. 4 août 2026 à 13:14 UTCidentified

   Lors d'un déploiement de service aujourd'hui, un sous-ensemble d'avions de contrôle a connu des redémarrages temporaires. Les clients touchés peuvent remarquer une brève indisponibilité de l'API pendant que ces avions de contrôle récupèrent. L'équipe surveille le rétablissement. Par ailleurs, les travaux visant à améliorer la capacité de l'infrastructure et la répartition des charges se poursuivent, comme nous l'avons décrit dans notre mise à jour initiale. Nous publierons une autre mise à jour une fois que les avions de contrôle affectés auront complètement stabilisé.

3. 4 août 2026 à 14:37 UTCidentified

   Nous procédons actuellement à des mesures d'échelle de mémoire pour régler les problèmes récurrents de stabilité lors des opérations de compactage sur les groupes touchés. De plus, nous prévoyons d'étendre la portée horizontale des grappes touchées aujourd'hui. Nous fournirons une autre mise à jour une fois que ces mesures auront été appliquées et nous pourrons en évaluer l'impact.

4. 4 août 2026 à 16:23 UTCidentified

   Nos plans pour une nouvelle échelle horizontale du plan de contrôle progressent. Nous nous attendons à pouvoir effectuer un essai à sec et d'autres essais dans les prochaines heures, avant de procéder à des migrations. Nous visons à terminer les travaux sur l'échelle horizontale jusqu'à l'EOD. Nous déployons des améliorations de configuration de mémoire en parallèle.

5. 4 août 2026 à 21:11 UTCmonitoring

   Les ajustements de mémoire ont été déployés et montrent des effets positifs. Nous entamons les migrations prévues pour améliorer encore les performances des avions de contrôle pour tous nos clients. Nous estimons que la migration sera terminée dans les prochaines heures. On s'attend à ce que la performance des plans de contrôle s'améliore déjà pendant la migration. Nous mettons cet incident en situation de surveillance et fournirons une mise à jour une fois la migration terminée.

6. 5 août 2026 à 06:23 UTCidentified

   La migration des premiers lots est terminée. L'équipe de Kubernetes a identifié un autre problème qui empêche de nouvelles migrations. Nous réactivons cet incident jusqu'à ce que le problème soit résolu et que la migration soit terminée.

7. 5 août 2026 à 10:07 UTCidentified

   La migration a été reprise. Nous voyons déjà des résultats encourageants après l'achèvement des premiers lots. Dans les prochaines heures, nous nous concentrons sur l'achèvement de la migration et de l'échelle horizontale. Au cours de la migration, un seul etcd peut être temporairement indisponible pendant des périodes d'environ 30 secondes. Nous attendons d'autres améliorations de performance et de stabilité pour tous les clients pendant et après la migration.

8. 5 août 2026 à 20:43 UTCidentified

   Les ajustements de la limite de mémoire et la migration ont eu des effets positifs sur le premier cluster du plan de contrôle. Le client situé dans le premier cluster d'avion de contrôle devrait déjà voir des améliorations substantielles dans les performances et la stabilité. Nous avons commencé à effectuer des réglages de mémoire dans le reste de l'amas. La suppression des limites de mémoire peut entraîner l'indisponibilité temporaire des plans de contrôle affectés. Ces interruptions devraient être brèves et n'affecteront pas la charge de travail. Une fois que les réglages de la limite de mémoire auront été entièrement effectués sur le deuxième cluster du plan de contrôle, l'échelle horizontale et les migrations reprendront sur les deux clusters du plan de contrôle pendant les prochaines heures jusqu'à ce que la charge de travail soit répartie de manière optimale.

9. 6 août 2026 à 08:04 UTCmonitoring

   Les ajustements de la limite de mémoire ont été entièrement déployés dans toutes les grappes du plan de contrôle et ont des effets positifs. Nous avons considérablement élargi la capacité d'infrastructure sous-jacente et la migration de la charge de travail des clients progresse bien. Nous observons des améliorations substantielles de la stabilité et des performances du plan de contrôle. Les modes de perturbation récurrents décrits dans les mises à jour antérieures ne sont plus présents. Le travail migratoire se poursuivra tout au long de la journée. Nous fournirons une mise à jour une fois les migrations terminées ou en cas de changement de statut.

10. 7 août 2026 à 05:06 UTCmonitoring

    La migration de la charge de travail des clients sur le premier cluster d'avions de contrôle a été achevée avant l'échéance. Les grappes de clients ont été redistribuées à travers une infrastructure élargie et toutes les charges de travail migrées fonctionnent sans problèmes. Nous continuons d'observer des performances stables du plan de contrôle sans nouvelles perturbations signalées.

11. 10 août 2026 à 19:58 UTCresolved

    Nous marquons cet incident comme résolu. Les mesures déjà mises en place ont eu l'effet souhaité sur le service et ont amélioré le rendement et la stabilité. Bien que cet incident soit marqué comme résolu, nous poursuivons l'exécution de notre plan d'action visant à améliorer la performance et la fiabilité de nos plans de contrôle Kubernetes gérés. Notre objectif actuel : - Autres équilibrages de charge sur nos clusters de contrôle - Migration des avions de contrôle vers une infrastructure améliorée

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 4 août 2026 à 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 août 2026 à 10:02 UTCresolved

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

1. 28 juillet 2026 à 13:46 UTCinvestigating

   Nous enquêtons actuellement sur un problème de connectivité touchant nos services DBaaS (MongoDB). Notre équipe travaille à résoudre le problème, et nous vous mettrons à jour dès que toutes les fonctionnalités ont été rétablies.

2. 28 juillet 2026 à 13:47 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 28 juillet 2026 à 13:51 UTCidentified

   Nous avons identifié un problème avec le DNS. Notre équipe DBaaS analyse actuellement le service. Un coupable potentiel a été identifié. Nous fournirons une autre mise à jour ici dernière 14:15

4. 28 juillet 2026 à 13:54 UTCmonitoring

   L'équipe DBaaS a effectué un retour en arrière d'un changement déployé avant la mise à jour des services DNS. Nous voyons les services se rétablir. Nous suivons la situation de près.

5. 28 juillet 2026 à 16:36 UTCresolved

   Nous marquons cet incident comme résolu car aucune autre anomalie n'a pu être détectée. Nous partagerons une ACR dès qu'elle sera compilée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 juillet 2026 à 06:27 UTCinvestigating

   Nous enquêtons sur les alertes liées à la perte de redondance sur les serveurs de stockage. Il n'y a actuellement aucun impact client, notre équipe de stockage enquête et travaille à restaurer la redondance. Nous soupçonnons un composant réseau défectueux.

2. 25 juillet 2026 à 06:44 UTCmonitoring

   Nous avons trouvé une cause probable. Une composante de gestion causait une consommation excessive de mémoire, introduisant l'instabilité sur les serveurs de stockage touchés. Cela a été atténué. Nous surveillons actuellement l'environnement et fermerons l'incident si aucune autre anomalie n'est observée.

3. 25 juillet 2026 à 07:49 UTCresolved

   Plus d'anomalies ont été détectées. La cause fondamentale de la perte de redondance a été identifiée comme une fuite de mémoire dans une composante de gestion. Une atténuation durable a été mise en place pour éviter les récidives. La fuite de mémoire sera abordée lors d'une prochaine mise à jour de la composante de gestion.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juillet 2026 à 06:51 UTCidentified

   Bien que le soutien téléphonique soit généralement disponible, notre capacité est réduite en raison de plusieurs cas de congé de maladie. Nous voulons vous informer que notre support téléphonique sera limité pendant les intervalles de temps suivants, ce qui entraînera des temps de réponse accrus sur le canal téléphonique. Dans ces cas, veuillez contacter par courriel. Je vous remercie.

2. 27 juillet 2026 à 05:43 UTCresolved

   La disponibilité du support Cloud est de retour. Merci de votre compréhension.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 juillet 2026 à 10:44 UTCinvestigating

   Nous enquêtons actuellement sur l'augmentation des taux d'erreur et des latences du Hub modèle d'IA. Plus de détails seront partagés dès qu'ils seront disponibles. Services touchés : Hub du modèle AI Lieu: Services mondiaux

2. 23 juillet 2026 à 11:25 UTCmonitoring

   Une correction a été mise en œuvre, qui a réduit le nombre de réponses 4xx et 5xx aux niveaux nominaux. Nous continuerons de surveiller les résultats.

3. 28 juillet 2026 à 07:12 UTCresolved

   Nous marquons cet incident comme résolu. Notre équipe de modèles d'IA a abordé la question, qui a été causée par de graves contraintes de ressources. Cela a été résolu en éliminant les goulets d'étranglement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 18 juillet 2026 à 13:33 UTCinvestigating

   Nous enquêtons actuellement sur un problème présumé de connectivité réseau qui influe sur le service des MK8. Nous garderons la page de statut à jour avec de nouvelles informations dès qu'elles seront disponibles.

2. 18 juillet 2026 à 13:55 UTCinvestigating

   L'enquête initiale rend peu probable la question de la connectivité du réseau. L'équipe concentre l'enquête sur le côté des Kubernetes gérés.

3. 18 juillet 2026 à 14:26 UTCidentified

   Nous avons identifié un pic dans la file d'attente des moteurs de ravitaillement qui est probablement la cause principale des problèmes observés. Notre équipe d'approvisionnement est informée et s'est jointe à la réponse.

4. 18 juillet 2026 à 14:47 UTCidentified

   Nous avons réduit la question et croyons que nous avons identifié le coupable. Nous confirmons actuellement cette conclusion.

5. 18 juillet 2026 à 15:03 UTCidentified

   Notre équipe de stockage a confirmé le coupable présumé. Nous atténuons actuellement la question et surveillerons l'exécution des tâches par la suite.

6. 18 juillet 2026 à 15:51 UTCidentified

   La question de l'entreposage a été résolue avec succès, mais à l'heure actuelle, la dotation en emplois ne progresse pas avec succès. Notre équipe d'approvisionnement enquête.

7. 18 juillet 2026 à 16:54 UTCidentified

   Bien que le bloc de provisionnement puisse être résolu, nous enquêtons sur un nombre accru d'erreurs liées au stockage. Nous attirons l'attention sur ces questions restantes. Les clients pouvaient encore voir des problèmes avec la fixation de stockages sur Kubernetes.

8. 18 juillet 2026 à 17:24 UTCidentified

   Nous avons trouvé un problème avec un serveur de stockage appartenant à une paire de serveurs de stockage redondants. Notre équipe met en œuvre une atténuation.

9. 18 juillet 2026 à 17:54 UTCmonitoring

   L'incident devrait maintenant être atténué. Le serveur de stockage affecté est en cours de restauration. Une fois cela terminé, la redondance sera entièrement rétablie. Nous ne voyons plus de problèmes de provisionnement. Nous surveillons la situation et la restauration, puis nous allons régler l'incident.

10. 18 juillet 2026 à 19:27 UTCmonitoring

    En raison de l'effort de restauration en cours sur le serveur de stockage clients pourraient encore voir l'impact résiduel lors de l'attache/deteaching stockage jusqu'à ce que la redondance est entièrement rétablie. Nous réinitialisons l'impact du service jusqu'au rendement dégradé.

11. 18 juillet 2026 à 20:24 UTCmonitoring

    L'équipe a rencontré une complication lors de la récupération du deuxième serveur de stockage dans la paire. Le matériel doit être remplacé. Notre équipe de datacenter travaille sur cette tâche. Pour les clients encore touchés, nous travaillons sur la mise en place d'une atténuation pour débloquer les opérations de stockage en parallèle.

12. 18 juillet 2026 à 21:31 UTCmonitoring

    On procède au remplacement du matériel. L'équipe continue d'atténuer les problèmes aigus d'approvisionnement en matériel jusqu'à ce que le remplacement et la récupération du matériel soient terminés afin de minimiser l'impact du client.

13. 18 juillet 2026 à 22:03 UTCmonitoring

    Le remplacement du matériel a été achevé. Le rétablissement de la redondance se poursuit.

14. 18 juillet 2026 à 22:43 UTCmonitoring

    Le premier remplacement de matériel a échoué. Une autre est tentée. Dans l'intervalle, une migration de données est en cours pour migrer les données vers une autre cible de stockage. En raison de la quantité de données à migrer, la migration est estimée à plusieurs heures.

15. 19 juillet 2026 à 12:21 UTCmonitoring

    La migration des entrepôts a été achevée, ce qui devrait éviter d'autres problèmes liés à la fixation du stockage. La migration des données instantanées est en cours, de sorte que les activités liées à l'instantané pourraient encore échouer.

16. 4 août 2026 à 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.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 juillet 2026 à 10:15 UTCidentified

   Bien que le soutien téléphonique soit généralement disponible, notre capacité est réduite en raison de plusieurs cas de congé de maladie. Nous voulons vous informer que notre support téléphonique sera limité pendant les intervalles de temps suivants, ce qui entraînera des temps de réponse accrus sur le canal téléphonique. 15.07.2026: 21:00 – 05:00 UTC 16.07.2026: 21:00 – 05:00 UTC Si possible, nous vous demandons de soumettre vos billets en utilisant le formulaire DCD ou par courriel. Merci de votre compréhension!

2. 17 juillet 2026 à 16:55 UTCresolved

   La couverture téléphonique est actuellement normale

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 13 juillet 2026 à 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 juillet 2026 à 11:21 UTCresolved

   This was a duplicate.