Ionos Cloud driftsforstyrrelser

1. 8. september 2026 kl. 14.15 UTCidentified

   Mens telefonsupport generelt vil være til rådighed, vores support kapacitet er reduceret på grund af flere tilfælde af sygefravær. Vi ønsker at informere dig om, at vores telefonsupport vil være begrænset i løbet af følgende tid slots, hvilket fører til øgede svartider på telefonkanalen. I disse tilfælde bedes du kontakte mig pr. e-mail. Tak.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 4. september 2026 kl. 16.53 UTCinvestigating

   Mens telefonsupport generelt vil være tilgængelig, er vores kapacitet reduceret på grund af flere tilfælde af sygeorlov. Vi ønsker at informere dig om, at vores telefonsupport vil være begrænset i løbet af følgende tid slots, hvilket fører til øgede svartider på telefonkanalen. I disse tilfælde bedes du kontakte mig pr. e-mail. Tak.

2. 7. september 2026 kl. 06.16 UTCidentified

   Vi mangler stadig dækning af service, og vi foretager i øjeblikket ændringer i vores billetsystem. Så vi beder venligst om din forståelse, hvis Support svar ikke er så rettidig, som du er vant til. Tak.

3. 8. september 2026 kl. 06.31 UTCresolved

   Vi har genetableret vores service. Support er tilbage. Tak for din tålmodighed.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. september 2026 kl. 13.36 UTCidentified

   For vores partnere med underentreprise: Vi fandt, at underentrepriser ikke kan få adgang til det nye Frankfurt sted "de / fra / 1". Vi arbejder på en rettelse for at gøre dette tilgængeligt, vi vil holde dig informeret, når det er gjort.

2. 1. september 2026 kl. 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. september 2026 kl. 16.12 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. august 2026 kl. 15.35 UTCinvestigating

   DCD er i øjeblikket ikke tilgængelig, viser en endeløs "Indlæser DCD"... side. Vi er i færd med at undersøge dette spørgsmål, og vil holde dig opdateret.

2. 31. august 2026 kl. 15.52 UTCmonitoring

   DCD 'en er nu tilgængelig igen, og vi overvåger situationen.

3. 31. august 2026 kl. 17.03 UTCresolved

   Vi markerer denne hændelse som løst. Vores netværksteam undersøger negativ indvirkning på IAM Services forårsaget af en ændring udrulning. Vi opdaterer statussiden, når årsagen er etableret.

4. 1. september 2026 kl. 15.32 UTCpostmortem

   * * * Foreløbig analyse af rodårsag * * Denne Root Cause Analyse er foreløbig, da forskning stadig udføres for at bestemme den tekniske rod årsag til hændelsen. Hvad skete der? Den 31. august 2026, mellem 15: 00 UTC og 15: 43 ITC, og igen mellem 16: 32 UTC og 16: 35 UTC, kunder var ude af stand til at nå IONOS Cloud Identity and Access Management\ (IAM\) service og Data Center Designer\ (DCD\), som er afhængig af denne tjeneste. Afbrydelsen påvirkede direkte login, partner og videreforhandler portal adgang, og tilknyttede management konsoller. Den samlede customer-vender virkning varede omkring 48 minutter på tværs af begge intervaller. Cloud Api 'er\ ([api.ionos.com] (http: / / api.ionos.com)\) forblev fuldt operationelle under hele hændelsen. De underliggende applikationstjenester var sunde hele tiden - fejlen var begrænset til netværkets kant lag. Hvordan var det muligt?\ (Root årsag\) * * Under en planlagt vedligeholdelse vindue på August 31, 2026, et netværk konfiguration opdatering blev anvendt til kant netværk infrastruktur med det formål at optimere routing filtre. Konfigurationen blev verificeret som korrekt før og under applikationen. Efter udrulningen, en routing formering anomali opstod på en kant netværk switch, forårsager asymmetrisk routing adfærd: indgående TCP-forbindelse anmodninger fra klienter blev lydløst tabt\ (sort- hul\) på netværket kant, før du når applikationsklyngen. Da applikationstjenesterne selv forblev sunde og sunde, var denne fejlfunktion ikke umiddelbart synlig gennem interne sundhedskontroller - tjenesterne blev isoleret fra at modtage indgående offentlig internettrafik i stedet for at svigte. Den grundlæggende årsag til, hvorfor denne specifikke kontakt viste asymmetrisk routing adfærd efter en ellers gyldig konfiguration ændring forbliver under aktiv undersøgelse. Hvorvidt dette blev udløst af en switch platform adfærd eller en software version- specifik fejl bliver bestemt gennem iscenesættelse miljø reproduktion. Hvad gør vi for at forhindre tilbagefald? # # * * Øjeblikkelig handling * * * * * Konfiguration Rollback: * * Ved at identificere routing anomali, en fuld rollback af netværket konfiguration blev udført på tværs af alle berørte kant kontakter. Routing meddelelser og TCP adgang til den offentlige produktion IP-adresser blev verificeret efter rollback. Alle berørte tjenester - DCD, Partner Portal, Reseller Portal, og IAM - blev bekræftet fuldt operationelle af 16: 35 UTC.\ (DONE\) # # # * * Kortsigt * * * * * Anbringelse af miljø replikation: * * Detaljerede testsager udføres i det iscenesættende miljø for at reproducere den nøjagtige routing formering adfærd under samme switch konfiguration betingelser. Målet er at afgøre, om anomalien kan tilskrives en specifik softwareversion fejl eller en switch platform adfærd, så den præcise fejl tilstand kan isoleres og behandles før nogen fremtidig udrulning. ETA: Inden for to uger # # * * Midtersigt * * * * * Revideret Rollout Strategi: * * Baseret på resultaterne fra iscenesættelse, vil en revideret udrulningsmetode blive designet til at sikre, at enhver fremtidig anvendelse af disse routing filter optimering kan udføres med større stabilitet garantier - herunder mere granulære validering checkpoints mellem switch-niveau ændringer. ETA: oktober 2026 # * * * Afsluttende bemærkninger * * Vi erkender, at tab af adgang til IAM og DCD har reelle operationelle konsekvenser. Det forhold, at de underliggende tjenester var sunde overalt, er ikke en afbødning af denne virkning. Vi er forpligtet til at sikre, at den grundlæggende årsag er fuldt forstået, før nogen re- forsøg på den oprindelige ændring, og at den reviderede udrulning strategi behandler de betingelser, der førte til den asymmetriske routing adfærd. Vi takker dig for din tålmodighed, mens vi afslutter efterforskningen.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 26. august 2026 kl. 09.53 UTCinvestigating

   Vi er i øjeblikket ved at undersøge øget latency påvirker S3 Object Storage i eu- central -1 regionen. Nogle kunder kan opleve langsomme svartider for læse og skrive operationer. Vores ingeniørteam arbejder aktivt på at løse problemet. Vi vil levere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

2. 27. august 2026 kl. 12.00 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 31. august 2026 kl. 17.08 UTCidentified

   Vi ser tilbagevendende latenstifter påvirke vores S3 service i eu- central-1. Objektlager- og netværksteam undersøger i fællesskab. Selv om en teknisk årsag forbliver ubestemt på nuværende tidspunkt, vores højeste prioritet er gennemførelsesforanstaltninger for at mindske hyppigheden og amplitude af pigge. Vi sætter pris på din tålmodighed og vil holde dig informeret.

4. 1. september 2026 kl. 15.18 UTCidentified

   Vores ingeniørhold har identificeret en vej til oprydning. Der er truffet de første foranstaltninger for at forbedre situationen for visse tjenester. Kunder, der bruger Objekt Storage i eu- central -1 kan fortsætte med at opleve forhøjet latency, som kan variere i sværhedsgrad. Arbejdet fortsætter på en omfattende fix. Vi vil levere yderligere opdateringer

5. 3. september 2026 kl. 08.27 UTCmonitoring

   Responstider for Objektlagring i eu- central-1 er forbedret betydeligt og fortsætter med at stabilisere. Vi overvåger nøje systemets ydeevne. Vi vil levere yderligere opdateringer som oprensning skrider frem.

6. 3. september 2026 kl. 13.39 UTCresolved

   Den øgede latenstid, der påvirker S3 Objektlagring i eu- central-1, er blevet løst. Responstiden er vendt tilbage til normale niveauer. Vi vil fortsat overvåge tjenesten.

7. 8. september 2026 kl. 12.25 UTCpostmortem

   "Root Cause Analysis Hvad skete der? Fra omkring 19: 00 UTC den 24 august 2026, kunder adgang til S3 Object Storage i Frankfurt\ (FRA4\) datacentret oplevede forhøjet latency på tværs af alle operationer - uploads, downloads, metadata anmodninger, og sletninger. Intermitterende HTTP 503 Service Utilgængelig og 404 Ikke Fundet fejl blev observeret på objekt læse anmodninger. Virkningen var målelig for alle kunder, der havde spande i de begge berørte datacentre i regionen, med nogle kunder oplever alvorlig nedbrydning afhængigt af deres spand konfiguration og adgangsmønstre. Name Hændelsen fortsatte med høj prioritet fra den 25. august til den 3. september 2026. Spørgsmålet om latency blev afbødet omkring 13: 40 UTC den 3. september 2026. Hvordan var det muligt?\ (Root årsag\) * * Primær årsag - Software fejl i kvalitet af tjenesten\ (QoS\) delsystem * * Name IONOS S3 Object Storage i Frankfurt region bruger et distribueret objekt storage system. En QoS-funktion i denne tjeneste - implementeret via en redis- qos-tjeneste - gælder hastighedsbegrænsning for S3-anmodninger på klyngeniveau. En fejl i S3-tjenesten fører til ikke godt distribuerede forespørgsler til Redis- QOS-tjenesten\ (som betjenes af flere servere for høj tilgængelighed\) Dette forårsagede Redis- QOS-processen til at nå og opretholde 100% CPU-udnyttelse, hvilket gradvis sinker alle S3-anmodninger behandling på klyngeniveau. Dette påvirkede alle anmodninger, der gik gennem de berørte knudepunkter, uanset hvilken type operation eller hvilken spand der var adgang til. Name Dette er en intern defekt i den anvendte software. Fejlen fik S3-tjenesten til at forbruge alle tilgængelige ressourcer, før belastningen nåede det ønskede niveau, der normalt ville udløse væltning, hvilket betyder, at nedbrydningen fandt sted kontinuerligt snarere end kun under spidsbelastningsforhold. Name I tæt samarbejde med software-leverandør, vi deaktiveret QoS rate- begrænsende funktion den 3 September, som helt løst latency spørgsmål. S3 fungerer i øjeblikket uden nogle QoS funktioner, mens en permanent fix er udarbejdet af sælgeren. Name Hvad gør vi for at forhindre tilbagefald? * * Allerede afsluttet: * * Name * QoS deaktiveret i S3 service - helt løst latency problem.\ (DONE\) * Anmoder om permanent løsning fra software leverandør.\ (INPROGRESS\) Name * * Kort sigt - ETA: inden for 2 uger: * * Name * Permanent fix for Cloudian QoS bug: IONOS Cloud er i aktiv koordinering med sælgeren for at få og implementere en fix for redis- qos defekt. Når fixet er valideret, vil tabte QoS-funktioner blive genaktiveret. * Database partition overvågning: Vi gennemfører overvågning, der advarer om partition størrelse vækst, før nogen individuel partition nærmer sig en problematisk tærskel. Dette vil gøre det muligt for vores team at identificere og behandle spand layout spørgsmål proaktivt. Name * * Middelvarighed - ETA: 1 til 3 måneder: * * Name * QoS arkitektur gennemgang: Efter den permanente QoS fix, vil vi gennemgå den arkitektoniske isolering af QoS service sammen med sælgeren for at sikre, at en fremtidig ressource stridence begivenhed i den rate- begrænsende lag ikke kan sprede sig til den anmodning sti på samme skala. * Overvågning og varsling forbedringer: Vi udvider cluster- niveau overvågning til overflade redis- qos CPU mætning og database compaction backlog som førsteklasses hændelse signaler, med automatiseret eskalering før customer- synlige latency udvikler. # # Afsluttende bemærkninger En hændelse af denne varighed i en central infrastrukturtjeneste er ikke acceptabel. Den høje latency periode varede i ni dage, hvor kundens arbejdsbyrde afhængigt af S3 i Frankfurt regionen blev forringet. Flere optimeringer og afbødningsstrategier blev gennemført i løbet af hændelsen, men kunne kun forbedre situationen for de enkelte spande og kun til en vis grad. Detektering af den underliggende QoS-fejl og udvikling af en afbødning krævede koordinering med sælgers engineering team. Name Mens spørgsmålet om latency er mildnet, vi forbliver i tæt kontakt med sælgeren. Den tekniske arbejde for at levere en permanent QoS fix, reducere database partition tryk, og forhindre gentagelse er i gang. Vi arbejder også tæt sammen med vores teknologipartner for at forstå forsinkelser i analysen af årsagen til denne hændelse. Vi vil foretage en fælles post mortem at identificere områder, hvor samarbejde under hændelser kan forbedres. Name Vi anerkender den indvirkning, denne hændelse forårsagede på dine operationer. Vi mener, at de anførte foranstaltninger vil hjælpe os med at forhindre lignende fejlmønstre og fremskynde analyse og inddrivelse af softwarerelaterede spørgsmål i fremtiden. Name Vi takker dig for din tålmodighed under hændelsen.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 23. august 2026 kl. 12.47 UTCinvestigating

   Vi er i øjeblikket ved at undersøge et problem, hvor Buckets og Objekt Storage Keys ikke vises i Data Center Designer. Det er i øjeblikket ikke muligt at få adgang til, ændre, oprette og slette Buckets og Keys via Data Center Designer.

2. 23. august 2026 kl. 17.48 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. august 2026 kl. 07.52 UTCinvestigating

   I øjeblikket er det ikke muligt at reservere eller håndtere IP-blokke, hverken i DCD, eller via API. Vores hold undersøger sagen. Vi holder dig opdateret.

2. 21. august 2026 kl. 08.18 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 23. august 2026 kl. 17.49 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. august 2026 kl. 14.50 UTCidentified

   Der kan være perioder med øgede ventetider, når du ringer til IONOS Cloud Support via telefon. Vi beder kunder og partnere om at kontakte Cloud Support via DCD Form eller e-mail, i stedet.

2. 17. august 2026 kl. 13.31 UTCidentified

   Situationen er stadig uændret, så bedst ville være at venligst nå ud via e-mail.

3. 20. august 2026 kl. 08.18 UTCresolved

   Det lykkedes os at komme tilbage til normal kapacitet, så Support er tilbage til normal tilgængelighed. Tak for tålmodigheden.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. august 2026 kl. 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. august 2026 kl. 12.42 UTCmonitoring

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

3. 14. august 2026 kl. 13.34 UTCresolved

   This incident has been resolved.

1. 13. august 2026 kl. 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. august 2026 kl. 08.04 UTCresolved

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

1. 11. august 2026 kl. 16.05 UTCinvestigating

   vi er i øjeblikket ved at undersøge øget fejlprocent for vores levering service.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 11. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 11.52 UTCresolved

   This incident has been resolved.

1. 4. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 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. august 2026 kl. 10.02 UTCresolved

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

1. 28. juli 2026 kl. 13.46 UTCinvestigating

   Vi er i øjeblikket ved at undersøge en forbindelse problem påvirker vores DBaaS (MongoDB) tjenester. Vores team arbejder på at løse problemet, og vi vil opdatere dig, så snart fuld funktionalitet er blevet genoprettet.

2. 28. juli 2026 kl. 13.47 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 28. juli 2026 kl. 13.51 UTCidentified

   Vi har identificeret et problem med DNS. Vores DBaaS team analyserer i øjeblikket tjenesten. Der er identificeret en potentiel gerningsmand. Vi vil levere endnu en opdatering her senest 14: 15

4. 28. juli 2026 kl. 13.54 UTCmonitoring

   The DBaaS Team har udført en rollback af en ændring indsat forud for opdaterede DNS-tjenester. Vi ser tjenester komme sig. Vi følger situationen nøje.

5. 28. juli 2026 kl. 16.36 UTCresolved

   Vi markerer denne hændelse så løst som ingen yderligere abnormiteter kunne detekteres. Vi deler en RCA, så snart den er udarbejdet.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 25. juli 2026 kl. 06.27 UTCinvestigating

   Vi efterforsker advarsler om tab af redundans på lagerservere. Der er i øjeblikket ingen kunde virkning, vores lagerhold undersøger og arbejder på at genoprette redundans. Vi mistænker en defekt netværkskomponent.

2. 25. juli 2026 kl. 06.44 UTCmonitoring

   Vi har fundet en mulig årsag. En forvaltningskomponent forårsagede et uforholdsmæssigt stort hukommelsesforbrug, der medførte ustabilitet på de berørte lagerservere. Dette er blevet mildnet. Vi overvåger i øjeblikket miljøet og vil lukke hændelsen, hvis der ikke observeres yderligere uregelmæssigheder.

3. 25. juli 2026 kl. 07.49 UTCresolved

   Ikke flere anomalier blev opdaget. Rodårsagen til tabet af redundans blev identificeret som en hukommelse lækage i en management komponent. Der blev indført en varig afbødning for at undgå gentagelse. Hukommelseslækage vil blive behandlet i en kommende opdatering til ledelsesdelen.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 24. juli 2026 kl. 06.51 UTCidentified

   Mens telefonsupport generelt vil være tilgængelig, er vores kapacitet reduceret på grund af flere tilfælde af sygeorlov. Vi ønsker at informere dig om, at vores telefonsupport vil være begrænset i løbet af følgende tid slots, hvilket fører til øgede svartider på telefonkanalen. I disse tilfælde bedes du kontakte mig pr. e-mail. Tak.

2. 27. juli 2026 kl. 05.43 UTCresolved

   Cloud Support tilgængelighed er tilbage. Tak for din forståelse.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 23. juli 2026 kl. 10.44 UTCinvestigating

   Vi er i øjeblikket ved at undersøge øgede AI Model Hub fejlrater og latesser. Flere detaljer vil blive delt, efterhånden som de bliver tilgængelige. Berørte tjenester: AI Model Hub Beliggenhed: Global Services

2. 23. juli 2026 kl. 11.25 UTCmonitoring

   Et fix er blevet implementeret, hvilket har reduceret antallet af 4xx og 5xx respons til nominelle niveauer. Vi vil fortsat overvåge resultaterne.

3. 28. juli 2026 kl. 07.12 UTCresolved

   Vi markerer denne hændelse som løst. Vores AI Modelhub Team har behandlet problemet, som var forårsaget af akutte ressourcemæssige begrænsninger. Dette blev løst ved at fjerne flaskehalsene.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 18. juli 2026 kl. 13.33 UTCinvestigating

   Vi er i øjeblikket ved at undersøge en mistanke netværksforbindelse problem påvirker MK8 service. Vi vil holde statussiden opdateret med nye oplysninger, efterhånden som de bliver tilgængelige.

2. 18. juli 2026 kl. 13.55 UTCinvestigating

   Den første undersøgelse gør et problem med nettilslutning usandsynlig. Holdet fokuserer på Managed Kubernetes side.

3. 18. juli 2026 kl. 14.26 UTCidentified

   Vi har identificeret en spike i vores levering motor kø, der er en sandsynlig årsag til de konstaterede problemer. Vores provisionshold er informeret og har tilsluttet sig svaret.

4. 18. juli 2026 kl. 14.47 UTCidentified

   Vi har indsnævret sagen og mener, at vi har identificeret den skyldige. Vi bekræfter i øjeblikket resultatet.

5. 18. juli 2026 kl. 15.03 UTCidentified

   Vores lagerhold har bekræftet den mistænkte. Vi er i øjeblikket ved at mindske problemet og vil overvåge leveringen af jobudførelse bagefter.

6. 18. juli 2026 kl. 15.51 UTCidentified

   Opbevaring problem er blevet løst med succes, men jobtilbud er i øjeblikket ikke fremskridt med succes. Vores provisionshold efterforsker.

7. 18. juli 2026 kl. 16.54 UTCidentified

   Mens provisionsblok kunne løses, vi undersøger et øget antal lagerrelaterede fejl. Vi retter opmærksomheden mod disse resterende spørgsmål. Kunderne kunne stadig se problemer med at vedhæfte lagre på Kubernetes.

8. 18. juli 2026 kl. 17.24 UTCidentified

   Vi har fundet et problem med en lagerserver, der tilhører en overflødig lagerserver par. Vores team gennemfører en afbødning.

9. 18. juli 2026 kl. 17.54 UTCmonitoring

   Hændelsen bør nu afbødes. Den berørte lagerserver bliver i øjeblikket genoprettet. Når dette er afsluttet, vil afskedigelser blive fuldt genoprettet. Vi kan ikke længere se nogen resterende provisionsspørgsmål. Vi overvåger situationen og genoprettelsen og vil derefter sætte hændelsen på plads.

10. 18. juli 2026 kl. 19.27 UTCmonitoring

    På grund af den igangværende restaurering indsats på lagerserveren kunder kan stadig se resterende virkning, når vedhæftning / løsrivning opbevaring indtil redundans er fuldt restaureret. Vi nulstiller virkningen af tjenesten tilbage til Degraded Performance.

11. 18. juli 2026 kl. 20.24 UTCmonitoring

    Holdet har mødt en komplikation under inddrivelse af den anden lagerserver i parret. Hardware skal udskiftes. Vores datacenter team arbejder på denne opgave. For kunder, der stadig er berørt, arbejder vi på at gennemføre en afbødning for at afblokere lageroperationer parallelt.

12. 18. juli 2026 kl. 21.31 UTCmonitoring

    Hardware udskiftning udføres. Holdet fortsætter med at afbøde akutte opbevaring levering problemer, indtil hardware udskiftning og inddrivelse er afsluttet for at minimere kundernes indvirkning.

13. 18. juli 2026 kl. 22.03 UTCmonitoring

    Hardware udskiftning blev afsluttet. Genoprettelsen af afskedigelsen fortsætter.

14. 18. juli 2026 kl. 22.43 UTCmonitoring

    Den første udskiftning af hardware mislykkedes. Endnu en er forsøgt. I mellemtiden en data migration kører for at migrere data til et andet lagringsmål. På grund af mængden af data, der skal migreres migreres migreringen skønnes at tage flere timer.

15. 19. juli 2026 kl. 12.21 UTCmonitoring

    Indvandringen af lagre er afsluttet, hvilket bør forhindre yderligere problemer med fastgørelse opbevaring. Migration af snapshotdata er i øjeblikket i gang, så snapshotrelaterede aktiviteter kan stadig ikke fuldføre med succes.

16. 4. august 2026 kl. 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.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. juli 2026 kl. 10.15 UTCidentified

   Mens telefonsupport generelt vil være tilgængelig, er vores kapacitet reduceret på grund af flere tilfælde af sygeorlov. Vi ønsker at informere dig om, at vores telefonsupport vil være begrænset i løbet af følgende tid slots, hvilket fører til øgede svartider på telefonkanalen. 15.07.2026: 21: 00 - 05: 00 UTC 16.07.2026: 21: 00 - 05: 00 UTC Hvis det er muligt, beder vi dig indsende billetter ved hjælp af DCD-formularen eller via e-mail. Tak for din forståelse!

2. 17. juli 2026 kl. 16.55 UTCresolved

   Telefondækning er i øjeblikket normal

Automatisk oversat fra den officielle hændelsesopdatering.