Störungsverlauf von Circle Ci

1. 4. September 2026 um 15:16 UTCinvestigating

   Wir haben Netzwerkprobleme festgestellt, die sich auf unsere Mac-Infrastruktur auswirken. Wir untersuchen und werden in Kürze Updates bereitstellen. Kunden können während dieser Zeit Schlange stehen.

2. 4. September 2026 um 15:43 UTCidentified

   Wir haben das Netzwerkproblem mit unserem Mac-Infrastrukturanbieter identifiziert und arbeiten mit ihnen zusammen, um das Problem zu lösen. Wir fangen an, eine gewisse Erholung zu sehen, aber wir erwarten, dass die Kunden immer noch Schlange stehen. Wir werden in Kürze wieder aktualisieren.

3. 4. September 2026 um 16:19 UTCmonitoring

   Unser Mac-Infrastrukturanbieter hat dieses Netzwerkproblem behoben und wir sehen, dass die Warteschlangenzeiten wieder normal werden. Wir werden die Dinge noch eine Weile im Auge behalten. Wir werden in Kürze wieder aktualisieren.

4. 4. September 2026 um 16:55 UTCresolved

   Wir haben keine weiteren Auswirkungen auf die Schlangenzeiten gesehen und alles hat sich wieder normalisiert. Wir schätzen Ihre Geduld, während wir daran gearbeitet haben, dieses Problem zu lösen und zu überwachen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. August 2026 um 15:43 UTCidentified

   Kunden können intermittierende Fehler beim Anzeigen von Plannutzungs-Benutzeroberflächen oder beim Aufrufen von Plannutzungs-APIs auftreten. Wir haben das Problem erkannt und arbeiten aktiv daran, diese Fehler zu mildern.

2. 26. August 2026 um 16:04 UTCmonitoring

   Wir haben das Problem mit Plannutzungs-APIs gemildert und die relevanten Seiten in der Benutzeroberfläche werden korrekt geladen.

3. 26. August 2026 um 16:10 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. August 2026 um 23:20 UTCresolved

   Zwischen 19:49 UTC und 21:07 UTC am 25. August 2026 konnten sich Kunden, die sich mit GitHub bei CircleCI anmelden wollten, nicht anmelden und erhielten einen Fehler von GitHub, der angab, dass die Rückruf-URL ungültig war. Kunden, die bereits angemeldet waren, waren nicht betroffen. Das Problem wurde behoben und GitHub Login funktioniert normal. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. August 2026 um 21:06 UTCidentified

   Die Ursache des Problems wurde ermittelt, und wir arbeiten daran, es zu beheben.

2. 17. August 2026 um 21:36 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 17. August 2026 um 21:37 UTCresolved

   Insights-Daten sind wieder einmal gut. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. August 2026 um 14:04 UTCidentified

   GitHub hat einen Vorfall gemeldet, der die CircleCI-Pipeline auslöst und anmeldet: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Jobs, die sich in Flügen befinden, laufen, aber die Statusmeldung an GitHub Pull Requests kann fehlschlagen.

2. 17. August 2026 um 14:25 UTCidentified

   Wir sehen weiterhin hohe Fehlerraten bei GitHub-APIs und reduzierten Webhook-Verkehr. Wir werden weiterhin Updates bereitstellen, sobald mehr Informationen verfügbar sind.

3. 17. August 2026 um 15:49 UTCidentified

   Wir sehen weiterhin hohe Fehlerraten bei den APIs von GitHub und reduzierten Webhook-Traffic. Kunden, die GitHub als VCS verwenden, können dadurch Auswirkungen auf ihre CircleCI-Plattform haben. Dies steht in direktem Zusammenhang mit dem Vorfall, den GitHub erlebt: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Wir werden Updates bereitstellen, sobald weitere Informationen verfügbar sind.

4. 17. August 2026 um 16:22 UTCmonitoring

   Wir haben begonnen, eine verbesserte Stabilität in GitHub-APIs zu beobachten. Wir werden weiter beobachten, wie sie sich erholen.

5. 17. August 2026 um 17:01 UTCmonitoring

   GitHub API Fehlerraten und Latenzen scheinen sich wiederhergestellt zu haben. Wir werden weiter beobachten.

6. 17. August 2026 um 17:23 UTCmonitoring

   Einige der APIs von GitHub sind immer noch degradiert, was zu einer kleinen Anzahl von Fehlern in Bezug auf Commit-Status-Updates und Hook-Verarbeitung führt. Wir werden weiterhin unser Bestes tun, um diese Auswirkungen zu mildern.

7. 17. August 2026 um 19:05 UTCresolved

   Die APIs von GitHub scheinen normal zu funktionieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. August 2026 um 13:58 UTCresolved

   Nach der geplanten Wartung, die am 15. August um 13:00 Uhr UTC endete, wurden einige Auswirkungen auf die Auftragsverarbeitung für etwa 30 Minuten über das von uns angekündigte Fenster hinaus fortgesetzt. Einige Kunden sahen weiterhin Verzögerungen bei den Jobs, zusammen mit einer kleinen Anzahl von Jobs, die mit Infrastrukturfehlern scheiterten, bis etwa 13:30 UTC. Dies wurde behoben und die Auftragsverarbeitung hat sich wieder normalisiert. Kunden, deren Jobs in diesem Fenster fehlgeschlagen sind, können betroffene Jobs erneut ausführen. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat, und entschuldigen uns für alle Unannehmlichkeiten, die die ausgedehnten Auswirkungen verursacht haben könnten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 12. August 2026 um 16:33 UTCidentified

   GitHub is currently experiencing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h). Customers who use GitHub as their VCS may experience impact to their CircleCI platform experience as a result, impacting checkout and workflows. We will provide another update as we have more information to share. Thank you for your patience.

2. 12. August 2026 um 16:43 UTCresolved

   The issue impacting customers who use GitHub as their VCS while GitHub was undergoing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h) has now been resolved. GitHub has resolved the underlying issue and the affected functionality has returned to normal. We thank you for your patience.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 11. August 2026 um 17:42 UTCresolved

   Between 13:50 UTC and approximately 17:30 UTC on August 11, 2026, some customers experienced delays of up to an hour in pipeline status updates and in notification delivery. Between 16:40 UTC and 17:00 UTC within that same window, a small number of customers also saw newly created pipelines fail to process, appearing in an errored state in the UI and API. The issue has been resolved and all affected functionality has returned to normal. Customers whose pipelines errored during that window can retrigger them. We thank you for your patience while our team worked on implementing a fix.

1. 6. August 2026 um 13:06 UTCinvestigating

   Usage API data is delayed for 8/5/2026. All prior data remains available. We are investigating. Thank you for your patience.

2. 6. August 2026 um 15:06 UTCidentified

   The issue has been identified and a fix is in progress.

3. 6. August 2026 um 19:33 UTCmonitoring

   A fix is in place and is being monitored. Thanks for your patience.

4. 6. August 2026 um 19:54 UTCresolved

   The Usage API issue has been resolved. Data has been loaded for yesterday, 8/5/2026. We appreciate your patience.

1. 5. August 2026 um 16:58 UTCinvestigating

   Wir sehen ein Problem mit dem Insights-Service, bei dem die Daten der letzten 24 Stunden hinterherhinken. Wir untersuchen.

2. 5. August 2026 um 17:46 UTCinvestigating

   We are continuing to investigate and will update as we know more.

3. 5. August 2026 um 18:25 UTCidentified

   We have identified the issue, and are working with our upstream provider to resolve it now.

4. 5. August 2026 um 21:01 UTCresolved

   The upstream issue has been resolved, and the insights data from the last 24 hours has caught up. Thank you for your patience.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 4. August 2026 um 19:27 UTCinvestigating

   We are experiencing increased queue times for Windows, Android, and GPU jobs due to capacity constraints with a third-party infrastructure provider. Jobs will continue to be processed but may take longer than usual to start. Thank you for your patience while our engineers work to resolve this.

2. 4. August 2026 um 19:59 UTCmonitoring

   We're starting to see queue times slowly recovering. We'll be monitoring this situation, we appreciate your patience.

3. 4. August 2026 um 20:33 UTCmonitoring

   Queue times continue to gradually recover with our third-party infrastructure provider, though we've seen a slight uptick in the last 30 mins. We're keeping an eye on this and will keep you updated as things get back to normal. Again, thank you for your patience.

4. 4. August 2026 um 21:16 UTCmonitoring

   Queue times for both Android and Windows jobs, which had been recovering, have started to rise again. This continues to be related to capacity constraints with our third-party infrastructure provider. We'll continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

5. 4. August 2026 um 21:46 UTCmonitoring

   Queue times for both Android and Windows jobs continue to be volatile, with sharp swings up and down. This remains related to capacity constraints with our third-party infrastructure provider. Our team will continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

6. 4. August 2026 um 22:20 UTCmonitoring

   Queue times for both Android and Windows jobs, affected by capacity constraints with our third-party infrastructure provider, have been recovering significantly for the last half hour. We're continuing to monitor for a bit longer to confirm they return to normal levels. We appreciate your patience.

7. 4. August 2026 um 23:40 UTCresolved

   Queue times for Android and Windows jobs have reduced significantly over the last hour. You may still notice brief, isolated queuing at times, but this is no longer at incident-level impact. This was related to capacity constraints with a third-party infrastructure provider. We thank you for your patience while we monitored the situation. If you have any issues, please reach out to our Support team.

1. 24. Juli 2026 um 16:35 UTCidentified

   GitHub erlebt derzeit eine Service-Degradation (https://www.githubstatus.com/incidents/yjysg0xrl67m). Kunden, die GitHub als VCS verwenden, können dadurch Auswirkungen auf ihre CircleCI-Plattform haben, was sich auf den Checkout und die Workflows auswirkt. Wir werden ein weiteres Update zur Verfügung stellen, da wir mehr Informationen teilen können. Vielen Dank für Ihre Geduld.

2. 24. Juli 2026 um 17:41 UTCresolved

   Das Problem, das Kunden betrifft, die GitHub als VCS verwenden, während GitHub sich einer Service-Degradation unterzog (https://www.githubstatus.com/incidents/yjysg0xrl67m), wurde nun behoben. GitHub hat das zugrunde liegende Problem behoben und die betroffene Funktionalität hat sich wieder normalisiert. Wir danken Ihnen für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Juli 2026 um 19:57 UTCinvestigating

   Wir untersuchen Verzögerungen bei der Aufnahme von Jobs mit der Ressourcenklasse gen3.

2. 22. Juli 2026 um 23:17 UTCinvestigating

   Wir untersuchen weiterhin erhöhte Wartezeiten, die sich auf Kunden auswirken, die Maschinenvollstrecker von gen3 verwenden. Betroffene Jobs können länger als gewöhnlich dauern, um zu beginnen. Wir werden ein weiteres Update zur Verfügung stellen, sobald wir mehr Informationen zu teilen haben.

3. 23. Juli 2026 um 00:31 UTCinvestigating

   Wir haben das Problem identifiziert und arbeiten mit unserem Anbieter zusammen, um die Verfügbarkeit von Gen-3-Ressourcen zu beheben. Gen 1 und Gen 2 sind beide voll funktionsfähig.

4. 23. Juli 2026 um 02:05 UTCresolved

   Zwischen 19:24 UTC am 22. Juli und 01:50 UTC am 23. Juli erlebten Kunden, die die Ressourcenklassen der Gen3-Vorschaumaschine (Linux VM) nutzten, Verzögerungen und in einigen Fällen, dass Jobs nicht starten konnten. Wir haben die Gen3-Ressourcenklassen entfernt, während wir uns mit Stabilitätsproblemen befassen, die sie betreffen. Leider wurden Workflows, für die wir in diesem Zeitraum keine Rechenkapazität bereitstellen konnten, abgebrochen. Betroffene Kunden sollten ihre Ressourcenklasse von gen3 zu gen2 ändern und diese Workflows erneut ausführen. Wir danken Ihnen für Ihre Geduld, während unser Team daran gearbeitet hat, dies zu lösen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. Juli 2026 um 06:13 UTCmonitoring

   Eine Untergruppe von Kunden hat möglicherweise Fehler beim Laden von app.circleci.com ab 03:18 UTC. Ein Fix wurde bereitgestellt und wir überwachen die vollständige Wiederherstellung. Vielen Dank für Ihre Geduld, während unsere Ingenieure die Genesung bestätigen. Wir werden in Kürze ein weiteres Update veröffentlichen.

2. 22. Juli 2026 um 06:27 UTCresolved

   Zwischen 03:18 UTC und 06:04 UTC am 22. Juli 2026 konnte eine Untergruppe von Kunden nicht auf app.circleci.com zugreifen. Das Problem wurde behoben und der Zugang hat sich wieder normalisiert. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Juli 2026 um 00:35 UTCidentified

   Wir haben ein Problem mit GitHub-API-Anforderungen identifiziert, das dazu führen kann, dass einige Kunden sehen, dass Workflows in einem laufenden Zustand stecken bleiben oder Workflows nicht starten. GitHub hat Vorfälle auf den APIs gemeldet https://www.githubstatus.com/incidents/ph5nns5y4gxj https://www.githubstatus.com/incidents/8vfyvq16hzh9 Wir überwachen die Stabilität von GitHub-APIs und werden diese Seite aktualisieren, sobald weitere Informationen verfügbar sind.

2. 20. Juli 2026 um 01:24 UTCidentified

   Wir sehen auch Fehler bei der Verarbeitung von Push-Event-Webhooks aufgrund des Upstream-API-Ausfalls. Benutzer müssen möglicherweise Pipelines für diese Push-Ereignisse wiederholen.

3. 20. Juli 2026 um 01:36 UTCmonitoring

   Wir sehen Anzeichen einer Erholung von der GitHub-API. Wir werden in einem Überwachungszustand bleiben, um zu überprüfen, ob sich die API-Fehlerrate erholt hat.

4. 20. Juli 2026 um 01:45 UTCresolved

   GitHub API-Fehlerraten haben sich auf ein normales Niveau erholt. Während des Vorfalls haben einige Kunden möglicherweise gesehen, dass Pipelines nicht starten oder keine Statusaktualisierungen erhalten. Einige Pipelines können in einem laufenden Zustand stecken bleiben. * Sie sollten Commits erneut pushen oder die Benutzeroberfläche verwenden, um Pipelines manuell auszulösen, die nicht gestartet wurden. * Pipelines in einem steckengebliebenen Zustand sollten abgebrochen und erneut ausgeführt werden. Wenn Sie Probleme haben, wenden Sie sich bitte an den CircleCI-Support.

5. 23. Juli 2026 um 21:10 UTCpostmortem

   ## Zusammenfassung Am 20. Juli 2026 von 00:22 bis 01:45 UTC erlebten CircleCI-Kunden, die unsere GitHub-Integrationen nutzten, Ausfälle bei der Ausführung von Pipelines und erlebten, dass Workflows stecken blieben. Während dieses Vorfalls konnten einige Pipelines, die von Benutzern mit GitHub ausgelöst wurden, nicht gestartet oder als Fehlerpipelines ausgeführt werden. Kunden, deren Pipelines während dieses Fensters ausgefallen sind oder als Fehlerpipelines ausgeführt wurden, sollten sie erneut ausführen. Dies wurde durch einen [upstream API-Abbau bei GitHub] (https://www.githubstatus.com/incidents/ph5nns5y4gxj) verursacht, der viele GitHub-APIs beeinflusste, die CircleCI zum Auslösen und Ausführen von Pipelines verwendet. Um 01:45 UTC erholten sich die GitHub-APIs und die Kundenpipelines liefen normal. Die ursprüngliche CircleCI-Statusseite finden Sie hier (https://status.circleci.com/incidents/9lvbbbs9l87b). ## Was geschah \(alle Zeiten UTC\) Ab 00:22 Uhr am 20. Juli 2026 begann GitHub, erhöhte Fehler für die folgenden API-Anforderungen zurückzugeben: * `Anwendungen/*/Token` „repos/*/commits „repos/*/*/contents/* „Repos/*/*/Hooks * `repos/*/*/hooks/*` * `repos/*/*/keys` „repos/*/*/pulls * `repos/*/*/status/*` CircleCI stützt sich auf diese Anforderungen, um Pipelines korrekt auszulösen und auszuführen. Um 00:22 Uhr hat uns unsere interne Überwachung auf das Problem aufmerksam gemacht. Unser Team begann zu untersuchen und stellte fest, dass eine kleine Anzahl von Pipelines, die zu GitHub-Projekten gehören, entweder nicht gestartet wurden oder als Fehlerpipelines ausgeführt wurden. Dazu gehörten geplante Pipelines und Workflows. Darüber hinaus erlebte eine kleine Anzahl von Kunden-Workflows festgefahrene Jobs und erforderte eine Wiederholung des Workflows. Um 01:45 Uhr erholte sich GitHub und die Pipeline-Verarbeitung kehrte auf das normale Betriebsniveau zurück. Nur Pipelines, die während des Ereignisfensters ausgelöst wurden, waren betroffen, und Kunden sollten diese Pipelines erneut ausführen. ## Zukünftige Prävention und Prozessverbesserung Wir arbeiten aktiv daran, die Belastbarkeit der Pipeline-Verarbeitung während GitHub-Serviceunterbrechungen zu verbessern, um die Auswirkungen ähnlicher Vorfälle auf den Kunden in Zukunft zu reduzieren. Wir erstellen Funktionen, die den Kunden helfen, sich mit reduzierten manuellen Schritten zu erholen, nachdem Vorfälle behoben wurden. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 23:04 UTCinvestigating

   Wir untersuchen ein Problem, bei dem Kunden möglicherweise Fehler beim Laden der CircleCI-Web-App und beim Anmelden sowie bei Pipelines und geplanten Workflows sehen, die nicht starten oder verspätet ausgeführt werden. Dies hängt mit einem anhaltenden Vorfall zusammen, der GitHub betrifft. Sie können den Status von GitHub unter https://www.githubstatus.com/incidents/gxycch3076xk verfolgen. Unsere Ingenieure untersuchen aktiv. Wir werden ein weiteres Update zur Verfügung stellen, sobald wir mehr Informationen zu teilen haben.

2. 16. Juli 2026 um 23:42 UTCidentified

   Wir sehen weiterhin hohe Fehlerraten von GitHub-APIs, die sich auf die Anmelde- und Workflowverarbeitung auswirken. Wir werden die GitHub-API weiterhin auf Wiederherstellung überwachen.

3. 17. Juli 2026 um 00:09 UTCmonitoring

   Was passiert Der vorgelagerte Vorfall, der GitHub betrifft, wurde gemildert und wird nun von GitHubs Seite überwacht. Sie können den Status von GitHub unter https://www.githubstatus.com/ verfolgen. Was können Sie erwarten Der Zugriff auf die CircleCI-Web-App, das Anmelden sowie die Pipeline- und Workflow-Verarbeitung werden wieder normal. Sie können immer noch intermittierende Fehler oder verzögerte geplante Pipelines und Workflows sehen, wenn sich die Systeme stabilisieren. Vielen dank für ihre geduld, während wir auf vollständige genesung achten.

4. 17. Juli 2026 um 00:26 UTCresolved

   Ein Vorfall, der die API von GitHub betraf, führte dazu, dass CircleCI-Kunden Fehler beim Laden der Web-App und beim Anmelden hatten, sowie Pipelines und geplante Workflows, die nicht starten oder verspätet ausgeführt wurden. GitHub hat den zugrunde liegenden Vorfall behoben (https://www.githubstatus.com/) und alle betroffenen Funktionen haben sich wieder normalisiert. Kunden, deren Jobs oder Pipelines fehlgeschlagen sind, können sie erneut ausführen. Geplante Pipelines und Workflows, die während des Vorfalls verpasst wurden, laufen nicht automatisch und müssen erneut ausgelöst werden. Wir danken Ihnen für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. Juli 2026 um 22:54 UTCidentified

   Am 13. Juli zwischen 15:30 UTC und 22:40 UTC kam es zu Verzögerungen beim Start von Jobs in den Ressourcenklassen Docker (Gen 2) aufgrund von Kapazitätsbeschränkungen unseres Cloud-Anbieters. Verzögerungen erreichten bis zu etwa 1 Minute 48 Sekunden. Wir erleben diese Verzögerungen seit ca. 15:45 UTC erneut. Bisher haben Verzögerungen bis zu etwa 1 Minute 19 Sekunden erreicht. Wir arbeiten mit unserem Cloud-Anbieter zusammen, um Kapazitäten hinzuzufügen, und werden diesen Vorfall aktualisieren, wenn sich die Situation ändert.

2. 15. Juli 2026 um 00:32 UTCresolved

   Am 13. Juli zwischen 15:30 UTC und 22:40 UTC kam es zu Verzögerungen beim Start von Jobs in den Ressourcenklassen Docker (Gen 2) aufgrund von Kapazitätsbeschränkungen unseres Cloud-Anbieters. Die gleiche Ausgabe wiederholte sich am 14. Juli zwischen 15:45 UTC und 22:50 UTC. Die Verzögerungen erreichten am 13. Juli bis zu 25 Minuten und am 14. Juli bis zu 24 Minuten. Die Ressourcenklassen medium+ und 2 X-large+ hatten die längsten Wartezeiten. Frühere updates in diesem vorfall berichteten zahlen basierend auf durchschnittlichen wartezeiten, die nicht die maximalen auswirkungen widerspiegelten, die einige kunden möglicherweise erlebt haben. Die Wartezeiten haben sich nun wieder normalisiert. Wir arbeiten weiterhin mit unserem Cloud-Anbieter zusammen, um die Kapazität vor der nächsten Hochsaison zu erhöhen. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 14. Juli 2026 um 02:49 UTCinvestigating

   Wir untersuchen derzeit Anmeldefehler, die einige Kunden betreffen, die Bitbucket als Identitätsanbieter verwenden.

2. 14. Juli 2026 um 03:29 UTCinvestigating

   Unser Team untersucht weiterhin Anmeldefehler, die einige Kunden betreffen, die Bitbucket als Identitätsanbieter verwenden.

3. 14. Juli 2026 um 03:51 UTCinvestigating

   Was ist betroffen Einige Kunden, die sich mit einer Bitbucket-gebundenen Identität anmelden, sind betroffen. Dies kann auch beinhalten, dass sich Kunden bei GitHub anmelden, aber eine verknüpfte Bitbucket-Identität auf ihrem Konto haben. Darüber hinaus erleben einige Kunden Workflows, die nicht gestartet oder aktualisiert werden. Was können Sie erwarten Betroffene Kunden können Login-Fehler sehen. Einige Kunden können auch Workflows bemerken, die nicht starten oder nicht wie erwartet aktualisiert werden. Vielen Dank für Ihre Geduld, während unsere Ingenieure untersuchen. Nächstes Update Wir werden ein weiteres update bereitstellen, sobald wir mehr informationen haben

4. 14. Juli 2026 um 04:21 UTCmonitoring

   Was ist betroffen Einige Kunden, die sich mit einer Bitbucket-gebundenen Identität anmelden, waren betroffen. Möglicherweise haben sich auch Kunden bei GitHub angemeldet, die eine verknüpfte Bitbucket-Identität auf ihrem Konto haben. Einige Kunden erlebten auch Workflows, die nicht gestartet oder aktualisiert wurden. Was können Sie erwarten Ein Fix wurde bereitgestellt. Wir beobachten die Situation, um eine vollständige Erholung zu bestätigen. Nächstes Update Wir werden ein Update bereitstellen, wenn sich etwas ändert

5. 14. Juli 2026 um 05:15 UTCresolved

   Das Problem, bei dem Kunden, die sich mit einer Bitbucket-gebundenen Identität anmelden, Anmeldefehler haben und bei einigen Kunden Workflows aufgetreten sind, die nicht gestartet oder nicht aktualisiert wurden, wurde behoben. Was Sie vielleicht noch erleben und tun müssen Wenn Sie Bitbucket als Anmeldemethode verwenden, loggen Sie sich bitte aus und authentifizieren Sie die CircleCI Bitbucket-Integration in Ihrem Konto. - Wenn einer Ihrer Workflows blockiert ist oder fehlende Statusüberprüfungen angezeigt werden, führen Sie diese bitte erneut aus, um den Fix abzuholen. - Wenn Sie nach diesen Schritten weiterhin Probleme haben, wenden Sie sich bitte an den CircleCI-Support. Wir danken Ihnen für Ihre Geduld, während unser Team an der Implementierung eines Fixes gearbeitet hat.

6. 14. Juli 2026 um 22:31 UTCpostmortem

   ## Zusammenfassung Von 01:33 UTC bis 05:18 UTC am 14. Juli 2026 konnten sich Kunden mit einer Bitbucket-gebundenen Identität nicht bei CircleCI anmelden, und einige Kunden erlebten Workflows, die aufgrund einer Änderung in der Art und Weise, wie der OAuth-Dienst von Bitbucket Kontoberechtigungen meldet, nicht gestartet oder aktualisiert wurden. Um 05:07 UTC haben wir einen Fix bereitgestellt, der korrigiert hat, wie unsere Systeme das Feld aktualisierte Berechtigungen gelesen haben. Einige Kunden mussten sich abmelden und ihre Bitbucket-Integration neu authentifizieren, nachdem wir den Fix bereitgestellt hatten. Unsere Systeme verarbeiteten den Rückstand der betroffenen Jobs bis 08:39 UTC weiter. Wir danken unseren Kunden für ihre Geduld, als wir diesen Vorfall gelöst haben. Bitte kontaktieren sie unser support-team mit fragen oder bedenken. Die Statusseite für diesen Vorfall finden Sie hier (https://status.circleci.com/incidents/gsyjwybg477g). ## Hintergrund CircleCI unterstützt die Anmeldung mit einem GitHub-Konto, einem Bitbucket-Konto oder einer E-Mail und einem Passwort. Wenn sich ein Kunde mit einer Bitbucket-gebundenen Identität anmeldet oder CircleCI den Zugang des Kunden in seinem Namen aktualisieren muss, tauschen wir ein Autorisierungstoken mit dem OAuth-Service von Bitbucket aus. Dieser Austausch enthält eine Liste der Berechtigungen oder "Scopes", die der Kunde uns erteilt hat und die Bitbucket und CircleCI verwenden, um zu bestätigen, was CircleCI im Namen des Kunden tun darf. ## Was geschah \(Alle Zeiten UTC\) Am 8. April 2026 kündigte Bitbucket eine Änderung seines OAuth-Dienstes an (https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3139): Es würde das Feld umbenennen, das verwendet wird, um die erteilten Berechtigungen eines Kunden zu melden. Bitbucket lief eine Übergangszeit, in der sowohl die alten als auch die neuen Feldnamen verfügbar waren, und entfernte dann den alten Feldnamen am 4. Mai 2026 vollständig. Unsere Systeme wurden nicht aktualisiert, um den neuen Feldnamen zu erkennen, und sobald Bitbucket den alten vollständig auslaufen ließ, begannen Anforderungen, die davon abhängig waren, zu scheitern. Um 01:33 Uhr am 14. Juli 2026 begannen unsere Systeme, Berechtigungsinformationen, die für Bitbucket-verknüpfte Konten zurückgegeben wurden, nicht zu verarbeiten, da unsere Systeme immer noch die alte Berechtigungsstruktur erwarteten. Dies führte dazu, dass Anmeldeversuche für alle Bitbucket-verknüpften Konten fehlschlugen, auch für Kunden, die sich bei GitHub anmelden, aber eine Bitbucket-Identität mit ihrem Konto verknüpft haben. Um 01:59 Uhr informierte die automatisierte Überwachung unser Engineering-Team über einen Anstieg der Fehler auf den betroffenen Systemen. Das Team begann sofort mit der Untersuchung, bestätigte die Auswirkungen der Kunden um 02:38 Uhr und alarmierte die Kunden über unsere Statusseite um 02:51 Uhr. Um 03:00 Uhr hatte das Team die Fehler im umbenannten Bitbucket-Feld isoliert. Ab 03:17 Uhr wurden Workflow-Statusupdates für Bitbucket-Pipelines von Kunden mit abgelaufenem Zugriffstoken eingestellt. Die Bitbucket-Berechtigungsprüfung wird auf unserer Plattform allgemein verwendet, und diese Berechtigungsfehler betrafen auch einige unserer internen Auftragsverarbeitungssysteme. Dies führte dazu, dass eine Teilmenge von Workflows ohne einen endgültigen Status stecken blieb, und führte dazu, dass einige Pull-Anforderungen fehlende oder festgefahrene Statusüberprüfungen anzeigten. Um 04:21 Uhr setzte das Team eine erste Korrektur ein, die das zugrunde liegende Problem löste, den Anmeldefluss wiederherstellte und unser internes Berechtigungssystem in den normalen Betrieb zurückbrachte. Einige betroffene Kunden mussten sich abmelden und wieder einloggen, um den Fix abzuholen. Um 05:07 Uhr setzte das Team zwei zusätzliche Korrekturen ein, damit unsere Systeme beginnen würden, das neue Berechtigungsfeldformat von Bitbucket zu akzeptieren. Wir haben den Vorfall um 05:18 Uhr gelöst. Einige Kunden mussten sich abmelden und ihre Bitbucket-Integration erneut authentifizieren, bevor ihr Konto vollständig wiederhergestellt wurde. Unsere Systeme verarbeiteten weiterhin einen Rückstand betroffener Jobs und kehrten um ca. 08:39 auf ein normales Niveau zurück. ## Zukünftige Prävention und Prozessverbesserung Wir unternehmen die folgenden Schritte, um eine Wiederholung zu verhindern und unsere Reaktionszeit zu verbessern: **Wir härten unseren Autorisierungscode gegen vorgelagerte API-Änderungen.** Dieser vorfall geschah, weil unser system ein umbenanntes feld in einer antwort eines drittanbieters nicht anmutig behandelte. Wir werden unseren Autorisierungscode sofort aktualisieren, damit unerwartete oder fehlende Felder von GitHub, Bitbucket und GitLab sicher gehandhabt werden. **Wir verbessern, wie wir Upstream-Provider-Änderungen verfolgen.** Wir überwachen derzeit bereits Changelogs von unseren Identitätsanbietern auf genau diese Art von bahnbrechenden Änderungen, aber wir haben diese spezielle Anbieteränderung nicht rechtzeitig zu unserer Überwachung hinzugefügt, um sie vor dem Versand zu fangen. Wir prüfen und erweitern dieses Monitoring, damit Anbieterankündigungen unser Team erreichen, bevor sie Kunden betreffen. **Wir verbessern, wie wir Vorfälle in ihren frühesten Minuten klassifizieren und kommunizieren. ** Die anfängliche Klassifizierung dieses Vorfalls spiegelte nicht sofort die Schwere des Kunden wider. Wir verfeinern unsere Incident-Tools und -Anleitungen, um Ingenieuren zu helfen, die Auswirkungen von Kunden schneller zu erkennen und zu kommunizieren. **Wir verbessern die Widerstandsfähigkeit unserer Workflow-Verarbeitungspipeline.** Ein Downstream-Fehler in diesem Vorfall führte dazu, dass einige Workflow-Statusaktualisierungen gelöscht wurden, anstatt erneut versucht oder deutlich aufgetaucht zu sein. Wir überprüfen das Wiederholungs- und Fehlerbehandlungsverhalten dieses Systems, so dass ähnliche nachgelagerte Fehler sichtbarer und leichter zu beheben sind. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Juli 2026 um 21:52 UTCinvestigating

   Wir haben einige Berichte über intermittierende Netzwerkprobleme zwischen unserer Mac-Infrastruktur und einem VCS-Anbieter erhalten. Wir untersuchen und werden Updates bereitstellen.

2. 13. Juli 2026 um 22:21 UTCinvestigating

   Wir untersuchen immer noch diese intermittierenden Netzwerkprobleme. Wir werden in Kürze wieder aktualisieren, wir schätzen Ihre Geduld.

3. 13. Juli 2026 um 23:13 UTCinvestigating

   Wir konnten das Problem reproduzieren, aber es scheint immer noch sehr intermittierend zu sein. Wir arbeiten weiterhin mit unserem Mac-Infrastrukturanbieter zusammen, um das Problem zu diagnostizieren. Wir werden bald wieder aktualisieren.

4. 13. Juli 2026 um 23:35 UTCmonitoring

   Wir haben das Problem erkannt. Bei einigen Kunden können Jobs auftreten, die während der Github-Abrufschritte aufgrund von intermittierenden Netzwerkproblemen hängen bleiben oder nicht vorankommen. Unsere Ingenieure überwachen aktiv. In der Zwischenzeit haben wir Erfolg mit der Erhöhung der no output timeout auf 15 - 20 min gesehen, um mehr Zeit für Github fetches zu ermöglichen. Dies kann durch folgende Community-Anleitung geschehen: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

5. 14. Juli 2026 um 13:59 UTCidentified

   Leider gibt es immer noch einige Kunden, die möglicherweise Jobs haben, die während der Github-Abrufschritte aufgrund von anhaltenden intermittierenden Netzwerkproblemen mit unserem Mac-Infrastrukturanbieter hängen bleiben oder nicht vorankommen. Unsere Ingenieure arbeiten aktiv mit ihnen zusammen, um dies zu lösen. Wir schätzen Ihre Geduld. In der Zwischenzeit haben wir Erfolg mit der Erhöhung der no output timeout auf 15 - 20 min gesehen, um mehr Zeit für Github fetches zu ermöglichen. Dies kann durch folgende Community-Anleitung geschehen: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

6. 14. Juli 2026 um 15:35 UTCidentified

   Unser Mac-Infrastrukturanbieter testet Änderungen an seiner Netzwerkkonfiguration, um die Ursache des Problems zu isolieren. Wir überprüfen aktiv, ob dies die Auswirkungen beseitigt, und werden bald ein weiteres Update durchführen. In der Zwischenzeit hilft die Erhöhung der no output timeout auf 15-20 min weiter: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

7. 14. Juli 2026 um 16:31 UTCidentified

   Wir haben das Problem als einige eingehende Routen vom betroffenen VCS-Anbieter identifiziert, die eine deutlich geringere verfügbare Bandbreite verursachen, was sich negativ auf die Repo-Abrufzeiten auswirkt. Wir arbeiten mit unserem Mac-Infrastrukturanbieter zusammen, um zu versuchen, den eingehenden Verkehr auf eine andere Route zu verlagern, aber dieser Prozess kann einen längeren Zeitraum in Anspruch nehmen. Wir werden weiterhin Updates bereitstellen, sobald sie verfügbar sind. Wie bereits in früheren Updates erwähnt, hilft die Erhöhung der no output timeout auf 15-20 min weiterhin: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

8. 14. Juli 2026 um 16:58 UTCmonitoring

   Unser Mac-Infrastrukturanbieter hat die eingehenden Routen verschoben und wir sehen eine Erholung in den VCS-Abrufzeiten. Wir werden dieses Problem in den nächsten Stunden weiter verfolgen. Wir werden bald wieder aktualisieren.

9. 14. Juli 2026 um 18:28 UTCmonitoring

   Wir sehen weiterhin eine langsame, progressive Erholung der VCS-Abrufzeiten. Wir werden die Überwachung und das Update bald fortsetzen. Wir schätzen Ihre Geduld.

10. 14. Juli 2026 um 20:18 UTCinvestigating

    Wir fangen an, VCS-Abrufzeiten wieder steigen zu sehen. Unser Engineering-Team untersucht aktiv und arbeitet mit unserem Mac-Infrastrukturanbieter zusammen, um dies zu beheben. Wiederum schätzen wir Ihre Geduld.

11. 14. Juli 2026 um 22:15 UTCmonitoring

    Unser mac-infrastrukturanbieter hat mehr traffic zu funktionierenden netzwerkanbietern verlagert und wir beginnen wieder eine signifikante wiederherstellung in den vcs-abrufzeiten zu sehen. Wie immer wird unser Engineering-Team dies weiterhin genau beobachten und wir werden bald ein weiteres Update bereitstellen.

12. 14. Juli 2026 um 23:18 UTCresolved

    Wir sehen weiterhin eine signifikante VCS-Recovery-Zeit in den letzten Stunden. Wir werden diesen Vorfall lösen und unser Ingenieurteam wird ihn weiterhin genau beobachten. Wir schätzen Ihre Geduld sehr, als wir dies mit unserem Mac-Infrastrukturanbieter durchgearbeitet haben. Bitte wenden Sie sich an unser Support-Team, wenn Sie Probleme haben.

13. 16. Juli 2026 um 01:56 UTCpostmortem

    ## Zusammenfassung Von 18:00 UTC am 13. Juli 2026 bis 23:18 UTC am 14. Juli 2026 erlebten einige Kunden, die Jobs auf der macOS-Flotte von CircleCI ausführen, Jobs, die während der GitHub-Schritte hingen oder nicht vorankamen. Für diese Kunden dauerten GitHub-Schritte, die normalerweise 1-2 Minuten dauern würden, 20-30 Minuten und wurden zeitlich begrenzt. Das Problem wurde durch ein Kapazitäts- und Routingproblem auf dem Netzwerkpfad zwischen unserem Mac-Infrastrukturanbieter und GitHub verursacht, und die damit verbundenen intermittierenden Netzwerkprobleme verlangsamten die Abrufe von GitHub. Während des gesamten Vorfalls arbeitete unser Team direkt mit unserem Mac-Infrastrukturanbieter zusammen, um den Datenverkehr von den betroffenen Netzwerkpfaden zu identifizieren und umzuleiten. Wir haben ein erstes Ereignis um 19:40 Uhr UTC am 13. Juli gelöst. Das Problem wiederholte sich am selben Tag um 21:52 UTC, wir eröffneten den Vorfall erneut und wurden am 14. Juli um 23:18 UTC vollständig gelöst. Unsere macOS-Flotte hatte vor einigen Wochen ein ähnliches Problem. Von 20:18 UTC am 24. Juni 2026 bis 03:09 UTC am 25. Juni 2026 erlebten Kunden einen [ähnlichen Vorfall] (https://status.circleci.com/incidents/gvysjmkf4ct9), der die Fähigkeit von macOS-Jobs beeinflusste, GitHub zu erreichen. Dieser Vorfall wurde auch durch ein Netzwerk-Routing-Problem in unserem Mac-Infrastrukturanbieter verursacht. Wir danken unseren Kunden für ihre Geduld, während wir diesen Vorfall durchgearbeitet haben. Bitte lesen Sie unten für spezifische Maßnahmen, die CircleCI und unser Mac-Infrastrukturanbieter ergreifen werden. Bitte kontaktieren sie unser support-team mit fragen oder bedenken. Die Statusseiten für diesen Vorfall finden Sie hier (https://status.circleci.com/incidents/n1tc2lw9q7l0) und hier (https://status.circleci.com/incidents/7cnl777wp9qz). ## Hintergrund Die macOS-Jobs von CircleCI werden auf einem Drittanbieter von Mac-Infrastruktur gehostet. Dieser Anbieter verbindet sich mit dem breiteren Internet, einschließlich Diensten wie GitHub, über mehrere redundante Upstream-Netzwerkpfade. Wenn auf einem dieser Pfade eine geringere Kapazität oder ein Routing-Problem auftritt, können Jobs, die Code oder Abhängigkeiten von einem Ziel entlang dieses Netzwerkpfads abrufen, sich verlangsamen oder intermittierend hängen, selbst wenn die eigene Plattform von CircleCI, der Infrastrukturanbieter eines Drittanbieters und der Zieldienst alle normal funktionieren. ## Was geschah \(Alle Zeiten UTC\) Um 18:00 Uhr am 13. Juli begannen einige Kunden, die macOS-Jobs ausführen, intermittierende Ausfälle und Verzögerungen beim Abrufen von Code und Abhängigkeiten von GitHub. Wir eröffneten eine Untersuchung und alarmierten unsere Kunden über unsere Statusseite um 18:55 Uhr. Bis 19:04 Uhr erkannte unser Mac-Infrastrukturanbieter eine erhöhte Latenz auf einem seiner Netzwerkpfade und leitete den Datenverkehr um ihn herum um. Die Abrufzeiten wurden wiederhergestellt, und wir bewegten den Vorfall um 19:29 Uhr auf "Monitoring" und um 19:40 Uhr auf "Resolved". Um 20:44 UTC berichteten Kunden, dass das Problem zurückgekehrt war. Wir haben den Vorfall erneut geöffnet und unsere Statusseite um 21:52 Uhr auf "Untersuchung" aktualisiert. In den folgenden zwei Stunden haben wir eng mit unserem Infrastrukturanbieter zusammengearbeitet, um Diagnosedaten zu sammeln, um den betroffenen Netzwerkpfad zu isolieren. In der Zwischenzeit haben wir Leitlinien veröffentlicht, in denen empfohlen wird, dass Kunden ihre Einstellung "no output timeout" auf 15-20 Minuten erhöhen, um GitHub-Rettungen während der intermittierenden Verlangsamungen mehr Zeit zu geben, und die Statusseite um 23:35 auf "Monitoring" verschoben. Nach der Veröffentlichung der Workaround-Anleitung um 23:35 UTC am 13. Juli erwarteten wir, dass sich das zugrunde liegende Netzwerkproblem über Nacht verbessern würde. Das war nicht der Fall. Um 13:59 UTC am 14. Juli bestätigten wir, dass die Kunden immer noch intermittierende Ausfälle hatten, und zogen die Statusseite zurück zu "Untersuchung". Unser Engineering-Team reproduzierte den Fehler direkt mit unseren eigenen Test-Tools, was dazu beitrug, dass dies ein allgemeines "git-fetch" -Problem war und nicht etwas, das für ein bestimmtes Build-Tool, Container-Image oder Software-Update spezifisch war. Um 15:35 Uhr haben wir die Statusseite aktualisiert, um mitzuteilen, dass unser Infrastrukturanbieter Änderungen an seiner Netzwerkkonfiguration getestet hat, um die Ursache des Problems zu isolieren. Um 16:31 Uhr haben wir die Statusseite erneut aktualisiert, um mitzuteilen, dass wir die Ursache als reduzierte eingehende Bandbreite auf einer bestimmten Route identifiziert haben und dass wir mit unserem Provider zusammenarbeiten, um den Datenverkehr auf eine andere Route zu verlagern. Um 16:36 Uhr identifizierte unser Infrastrukturanbieter die betroffenen Netzwerkpfade und verlagerte den Datenverkehr von ihnen, holte die Zeiten wiederhergestellt, und um 16:58 Uhr aktualisierten wir die Statusseite auf "Monitoring". Am frühen Nachmittag sahen einige Kunden wieder langsame Abrufzeiten und wir zogen die Statusseite um 20:18 Uhr wieder auf "Untersuchung". Unser Infrastrukturanbieter identifizierte zwei zusätzliche Netzwerkpfade mit eingeschränkter Leistung und verlagerte den Datenverkehr um 22:07 Uhr von ihnen. Die Abrufzeiten stabilisierten sich über die folgende Stunde, und wir markierten den Vorfall um 23:18 Uhr "gelöst". Insgesamt können Kunden, die Mac-Jobs ausführen, zwischen 18:00 UTC am 13. Juli und 23:18 UTC am 14. Juli intermittierende Jobverlangsamungen oder Ausfälle in Teilen des Fensters erlebt haben. Unser Infrastrukturanbieter hat seitdem saubere Testergebnisse in seinem Netzwerk gemeldet und glaubt, dass das zugrunde liegende Kapazitätsproblem weiter vorgelagert, näher bei GitHub, und nicht innerhalb seines eigenen Netzwerks entstanden ist. Wir werden dies weiterhin genau beobachten. ## Zukünftige Prävention und Prozessverbesserung Wir unternehmen die folgenden Schritte, um eine Wiederholung zu verhindern und unsere Reaktionszeit zu verbessern: **Wir bauen zusätzliche automatisierte Überwachung für macOS Flotte GitHub-Fetch Leistung. ** Unsere umfangreiche automatisierte Überwachung hat diesen Vorfall nicht erfasst. Wir fügen jetzt eine End-to-End-Überwachung insbesondere für GitHub-Fetzen hinzu, um ähnliche Probleme proaktiv zu erkennen. **Wir arbeiten direkt mit unserem Mac-Infrastrukturanbieter an einer schnelleren, proaktiveren Erkennung.** Wir bitten unseren Anbieter, ein Monitoring zu erstellen, das einen degradierten Netzwerkpfad erkennen und automatisch um ihn herum umleiten kann, anstatt sich auf CircleCI zu verlassen, um eine Umleitung während eines aktiven Vorfalls zu identifizieren und anzufordern. **Wir verwandeln die Diagnosewerkzeuge, die wir während dieses Vorfalls gebaut haben, in eine Stehfähigkeit. ** Auf diese Weise können wir diese Klasse von Netzwerkausfällen bei Bedarf erkennen und reproduzieren, anstatt die Testinfrastruktur während eines aktiven Vorfalls zusammenzustellen. **Wir überprüfen unseren Incident Response-Prozess auf ein ausreichendes Bestätigungsfenster, bevor wir einen netzwerkbezogenen Incident Resolved markieren.** Dieser vorfall wiederholte sich kurz nach einer vorzeitigen lösung; wir formalisieren eine mindestzeit der bestätigten sauberen Überwachung, bevor vorfälle dieser art abgeschlossen werden. Wir werden weiterhin regelmäßige Updates auf dem Weg zur Verfügung stellen, während die Untersuchung und Sanierung fortgesetzt wird. **Wir bewegen uns aktiv von einem einzigen Anbieter für Mac-Infrastruktur** zu mehreren Anbietern.** Dies ermöglicht CircleCI, eingehende Kunden-Workloads an den verfügbarsten und leistungsstärksten Anbieter zu leiten. Die Kundenerfahrung ist unsere oberste Priorität, und wir verpflichten uns, die Zuverlässigkeit unserer Systeme kontinuierlich zu verbessern, um dem Vertrauen unserer Kunden in uns gerecht zu werden. Bitte kontaktieren sie unser support-team mit fragen oder bedenken.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Juli 2026 um 18:55 UTCinvestigating

   Wir haben Berichte über intermittierende Netzwerkprobleme zwischen unserer Mac-Infrastruktur und einem VCS-Anbieter erhalten. Wir untersuchen und werden Updates bereitstellen.

2. 13. Juli 2026 um 19:11 UTCidentified

   Wir arbeiten mit unserem Mac-Infrastrukturanbieter zusammen, um eine Minderung zu versuchen. Wird in Kürze wieder aktualisiert.

3. 13. Juli 2026 um 19:29 UTCmonitoring

   Unser Mac-Infrastrukturanbieter hat einen Fix implementiert, wir beginnen, eine Wiederherstellung zu sehen. Wir überwachen und werden in Kürze erneut aktualisieren.

4. 13. Juli 2026 um 19:40 UTCresolved

   Wir haben den Fix mit unserem Infrastrukturanbieter und erfolgreichen Tests an unserem Ende bestätigt. Wenn kunden weiterhin fehlgeschlagene läufe sehen, führen sie bitte erneut eine erfolgreiche verbindung durch und wenden sie sich bei weiteren problemen an den support.

Automatisch aus der offiziellen Störungsmeldung übersetzt.