Störungsverlauf von Cycode

1. 27. Oktober 2026 um 10:06 UTCinvestigating

   **Zusammenfassung** Einige Bitbucket-Cloud-Integrationen, die OAuth verwenden, nachdem der Authentifizierungsdienst von Bitbucket am 27. Oktober 2026 um 03:45 UTC Fehler zurückgegeben hatte. **Auswirkungen** Bei betroffenen Integrationen kann Cycode nicht auf Bitbucket zugreifen. Scans, Repository-Synchronisierungen und Commit-Status für diese Arbeitsbereiche werden gestoppt, bis die Integration erneut autorisiert ist. Integrationen, die App-Passwörter, API-Token oder Workspace-Zugriffstoken verwenden, sind nicht betroffen. ** Letztes Update** Unsere Untersuchung zeigt, dass Bitbucket neue Anmeldeinformationen für diese Integrationen ausgestellt hat, diese jedoch nicht an Cycode geliefert hat, da sein Dienst einen Fehler zurückgegeben hat. Bitbucket akzeptiert die vorherigen Anmeldeinformationen nicht mehr, sodass die Integrationen nicht automatisch wiederhergestellt werden können. Wir melden das Problem an Atlassian. **Aktion erforderlich ** Wenn Ihre Bitbucket-Integration als getrennt angezeigt wird, autorisieren Sie sie erneut in der Cycode-Konsole unter [Einstellungen > Integrationen > Bitbucket]. Cycode fährt fort, von wo es aufhörte, und keine andere Änderung ist notwendig. Wir werden ein Update veröffentlichen, wenn wir mehr Informationen haben.

2. 27. Oktober 2026 um 10:46 UTCmonitoring

   Wir haben jede betroffene Integration identifiziert und kontaktieren nun ihre Benutzer direkt. Eine Integration beginnt wieder zu funktionieren, sobald ihr Benutzer sie in der Cycode-Konsole unter [Einstellungen > Integrationen > Bitbucket] erneut autorisiert. Wir haben den Bitbucket-Fehler an Atlassian gemeldet und werden ein Update veröffentlichen, wenn wir weitere Informationen haben.

3. 27. Oktober 2026 um 12:51 UTCresolved

   Alle betroffenen Bitbucket Cloud-Integrationen wurden identifiziert und ihre Benutzer erhielten Anweisungen, sie erneut zu autorisieren. Integrationen, die autorisiert wurden, funktionieren wieder normal. Die Ursache war ein Bitbucket-Servicefehler am 27. Oktober 2026 um 03:45 Uhr UTC, der die Anmeldeinformationen einiger Integrationen ungültig machte. Wir teilten die Details mit Atlassian für ihre Untersuchung.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Oktober 2026 um 09:28 UTCinvestigating

   Wir haben eine mögliche Ursache für die Login-Flow-Probleme identifiziert und untersuchen weiter.

2. 20. Oktober 2026 um 09:54 UTCinvestigating

   Wir haben das Login-Flow-Problem in der EU-Region gelöst.

3. 20. Oktober 2026 um 10:04 UTCmonitoring

   Das Problem wurde gelöst, und wir überwachen das System weiterhin, um Stabilität zu gewährleisten.

4. 20. Oktober 2026 um 15:43 UTCresolved

   Der Vorfall wurde vollständig gelöst, und wir sehen keine weiteren Probleme.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. Oktober 2026 um 13:10 UTCinvestigating

   Wir untersuchen Fehler in der Anwendung im Zusammenhang mit PR-Scans und Verletzungslastausfällen. Wir werden weitere Updates veröffentlichen, sobald wir die Ursache gefunden haben.

2. 18. Oktober 2026 um 13:26 UTCidentified

   Wir hatten ein Problem mit einer unserer Anwendungsdatenbanken. Die Datenbank ist wieder normal, aber immer noch degradiert, und wir arbeiten aktiv daran, sie zu beheben. Die Plattform ist wieder normal, und Verstöße und PR-Scans sollten normal funktionieren.

3. 18. Oktober 2026 um 13:34 UTCmonitoring

   Die Datenbank ist wieder im normalen Betrieb. Wir überwachen aktiv, um sicherzustellen, dass es keine verbleibenden Probleme gibt.

4. 18. Oktober 2026 um 14:40 UTCresolved

   Der Vorfall wurde vollständig gelöst, und wir sehen keine weiteren Probleme.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 12:56 UTCmonitoring

   **Monitoring**: scannt API (US-Region) Zuvor hat unser Warnsystem festgestellt, dass der Dienst hinter der Scan-API häufiger als erwartet neu gestartet wurde, was dazu führte, dass einige Anfragen für kurze Zeit fehlschlugen. Wir haben das für den Dienst verfügbare Gedächtnis erhöht, und es ist seitdem stabil. Wir halten den Service unter genauer Beobachtung, während wir eine dauerhafte Verbesserung abschließen.

2. 13. Oktober 2026 um 13:01 UTCresolved

   **Aufgelöst**: Kurze Verlangsamung der Scans API (US-Region) Am 13. Oktober 2026, zwischen 07:58 und 08:28 UTC, einige Anfragen Die Scan-API in der US-Region ist fehlgeschlagen oder langsam. Scan-Seiten in der Cycode-Benutzeroberfläche und der Cycode-CLI haben möglicherweise temporäre Fehler gezeigt, und einige Pull-Request-Scans kamen einige Minuten später als üblich an. Wir haben den für den Dienst verfügbaren Speicher erhöht, was das Problem um 08:34 UTC vollständig behoben hat. Alle Warteschlangen-Scans wurden kurz danach abgeschlossen, und es gingen keine Daten verloren. Wir haben die Ursache identifiziert und eine dauerhafte Verbesserung wird überprüft.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 08:30 UTCinvestigating

   GitLab erlebt derzeit eine Serviceunterbrechung, die sich auf das PR-Scannen und die Integrationsverbindung von Cycode auswirken kann. Das Problem stammt aus der Infrastruktur von GitLab und liegt außerhalb der Kontrolle von Cycode. Wir überwachen die Situation und werden Updates bereitstellen, da GitLab daran arbeitet, den normalen Service wiederherzustellen. Weitere Informationen finden Sie auf der Statusseite von GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614)

2. 13. Oktober 2026 um 08:47 UTCmonitoring

   GitLab hat den Vorfall mit Auswirkungen auf PR-Scanning und Integrationskonnektivität in die Überwachungsphase verlagert. GitLab hat einen Fix implementiert und überwacht die Ergebnisse. Wir überwachen weiterhin die Auswirkungen auf Cycode-Integrationen und werden bei Bedarf weitere Updates bereitstellen. Weitere Informationen finden Sie auf der Statusseite von GitLab: [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614)

3. 13. Oktober 2026 um 11:27 UTCresolved

   GitLab hat den Vorfall mit Auswirkungen auf PR-Scanning und Integrationsverbindung behoben

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 14:22 UTCinvestigating

   Das Team arbeitet weiterhin mit AWS zusammen, was das Problem intern eskaliert hat. Parallel dazu arbeiten wir daran, die Funktionalität wiederherzustellen, indem wir in eine andere Datenbank wechseln. Alle blockierten Pull-Anfragen, die auf den Cycode-Status warten, können freigegeben werden, indem Cycode-Scans aus den erwarteten Prüfungen direkt in Ihrem SCM (Source Code Management) entfernt werden. Wenden Sie sich an Ihren Cycode-Vertreter, um den Prozess zu optimieren.

2. 7. Oktober 2026 um 14:22 UTCinvestigating

   AWS hat bestätigt, dass sich die betroffene PostgreSQL-Instanz derzeit in einem internen Wiederherstellungszustand befindet. Der erwartete Multi-AZ-Failover fand nicht wie geplant statt, und AWS untersucht aktiv, warum. Parallel dazu arbeiten wir weiter daran, die betroffenen Dienste mit einem alternativen Datenbankpfad wiederherzustellen, um die Wiederherstellung zu beschleunigen

3. 7. Oktober 2026 um 14:22 UTCinvestigating

   Wir sehen, dass die Datenbank ihre operativen Kapazitäten wiederherstellt. Wir sehen, dass erste Pull Request Scans verarbeitet werden. Wir überwachen das System und erhöhen den Durchsatz.

4. 7. Oktober 2026 um 14:22 UTCinvestigating

   Die Datenbank bleibt voll funktionsfähig. Wir arbeiten daran, die Verarbeitungsgeschwindigkeit über die reguläre hinaus zu erhöhen, um alle Backlogs so schnell wie möglich zu verarbeiten.

5. 7. Oktober 2026 um 14:22 UTCinvestigating

   Wir untersuchen weiterhin eine erhebliche Verschlechterung der US-Plattform, die durch die Erschöpfung der PostgreSQL-Verbindung verursacht wird. Kunden können langsame Reaktionszeiten, erhöhte 500-Fehler und langsamere PR-Workflows und CLI-Scans erleben. Wir haben die Datenbankbelastung für mehrere Dienste reduziert und ein RDS-Failover initiiert. Das Team arbeitet aktiv daran, die normale Leistung wiederherzustellen.

6. 7. Oktober 2026 um 14:22 UTCinvestigating

   Wir haben eine verschlechterte Leistung in prod-us festgestellt Flows wie Pull Request oder CLI-Scanning können langsamer als üblich sein

7. 7. Oktober 2026 um 14:22 UTCinvestigating

   Das Team arbeitet aktiv mit AWS zusammen und untersucht, was ein Failover-Problem mit Datenbanken zu sein scheint, das die US-Umgebung beeinflusst. Wir werden ein weiteres Update teilen, sobald wir mehr Informationen haben.

8. 7. Oktober 2026 um 14:22 UTCinvestigating

   Die US-Plattform verbessert sich nach der früheren Erschöpfung der RDS/PostgreSQL-Verbindung. AWS hat bestätigt, dass die ursprüngliche PostgreSQL-Instanz in einen Betriebszustand zurückgekehrt ist, und wir sehen, dass PR-Scans erneut verarbeitet werden. Der größte verbleibende Abbau ist die verzögerte GitHub-gesteuerte Verarbeitung aufgrund eines großen Webhook-Backlogs, der weiterhin abläuft. Wir werden die Wiederherstellung weiterhin überwachen und ein weiteres Update bereitstellen, wenn die Verarbeitung wieder normal wird

9. 7. Oktober 2026 um 14:22 UTCinvestigating

   Das System ist wieder voll funktionsfähig

10. 7. Oktober 2026 um 14:22 UTCresolved

    (2/2) • Unterbrach die Workloads, die hohe Mengen an kurzlebigen Datenoperationen verursachten, um die Datenbanklast zu reduzieren, während verzögerte Ereignisse gelöscht wurden. • Scannen der Pull-Anfragen, die während des Vorfalls verpasst wurden. **4b. Aktionspunkte** • Ändern Sie, wie große Datenchargen geschrieben werden, um die Datenbanklast zu reduzieren. • Verschieben Sie unsere volumenstärkste Workload in eine eigene dedizierte Datenbank, so dass ein Problem dort den Rest der Plattform nicht beeinflussen kann. • Hinzufügen von Benachrichtigungen und einer tieferen Überwachung der Nutzung der Datenbankverbindung und des Datenbankzustands. • Geben Sie jedem Dienst seine eigenen dedizierten Datenbankanmeldeinformationen. • Verarbeiten Sie eingehende Ereignisse effizienter, um die Wiederherstellung nach einer Störung zu beschleunigen. • Verbesserte Überwachung von Verarbeitungsverzögerungen und internen Ereigniswarnungen. • Überprüfen Sie die Datenbankkapazitäts- und Leistungseinstellungen, um mehr Headroom hinzuzufügen.

11. 7. Oktober 2026 um 14:22 UTCresolved

    (1/2) **1. Zusammenfassung** Am 5. Oktober 2026, ab 15:55 Uhr IDT, sahen Kunden auf unserer US-Plattform langsame Antworten, intermittierende Fehler und Verzögerungen bei Pull-Request-Checks und CLI-Scans. Einige Kunden, deren Repositories Cycode Pull Request Checks erfordern, konnten nicht zusammengeführt werden, bis das Scannen wieder aufgenommen wurde. Das Problem begann, als ein Hintergrundwartungsprozess in unserer primären Datenbank zurückfiel und nicht mehr abgeschlossen wurde und die Datenbank keine neuen Daten mehr speicherte. Der Restaurierungsservice dauerte mehrere Stunden, da die Standby-Datenbank zunächst einen großen Änderungsbestand verarbeiten musste. Die Datenbank war zurück und die Plattform war bis 19:43 IDT wieder verfügbar. Die verzögerte Verarbeitung holte dann auf und der Vorfall wurde um 23:24 IDT behoben. Pull-Anfragen, die während des Vorfalls verpasst wurden, wurden gescannt. **2. Key Timeline (IDT)** • **Oktober 5, 2026, 12:55 IDT**: Ein routinemäßiger Datenbankwartungsprozess beginnt viel langsamer als normal. Noch keine Kundenauswirkungen. • **Oktober 5, 2026, 14:53 IDT**: Der nächste Wartungszyklus beginnt und wird nicht abgeschlossen. • **Oktober 5, 2026, 15:55 IDT**: Die Datenbank stoppt das Speichern neuer Daten und die Plattformleistung verschlechtert sich. • **Oktober 5, 2026, 16:03 IDT**: Die Datenbank erreicht ihre Verbindungsgrenze. Kunden beginnen Fehler zu sehen. • **Oktober 5, 2026, 16:21 IDT**: Vorfall erklärt und Reaktionsteam engagiert. • **Oktober 5, 2026, 16:24 IDT**: Erstes Update auf der Statusseite. • **Oktober 5, 2026, 16:49 IDT**: Wechseln Sie zur Standby-Datenbank gestartet. • **Oktober 5, 2026, 17:00 IDT**: Der Supportfall wurde mit unserem Cloud-Infrastrukturanbieter eröffnet. • **Oktober 5, 2026, 18:24 IDT**: Der alternative Wiederherstellungspfad begann parallel. Workaround für Kunden veröffentlicht, die durch erforderliche Pull Request Checks blockiert wurden. • **Oktober 5, 2026, 19:43 IDT**: Datenbank wieder verfügbar, und die Cycode API und Cycode Platform sind zugänglich. • **Oktober 5, 2026, 19:54 IDT**: Pull Request Scanning Lebensläufe. • **Oktober 5, 2026, 20:20 IDT**: Die Verarbeitungskapazität wurde erhöht, um verzögerte Ereignisse zu löschen. • **Oktober 5, 2026, 20:45 IDT**: Hochvolumige Workloads wurden angehalten, um die Datenbanklast zu reduzieren. • **Oktober 5, 2026, 21:56 IDT**: Pull-Anfragen, die während des identifizierten und gescannten Vorfalls verpasst wurden. • **Oktober 5, 2026, 23:09 IDT**: Alle Dienste sind voll funktionsfähig. • **Oktober 5, 2026, 23:24 IDT**: Vorfall behoben. **3. Wurzelursache** Unsere Datenbank führt einen routinemäßigen Hintergrundprozess durch, der regelmäßig aktuelle Änderungen an der dauerhaften Speicherung speichert. Zwei Bedingungen trugen dazu bei, dass sich dieser Prozess verlangsamte: • **Hochvolumige kurzlebige Datenoperationen:** Einige unserer Verarbeitungs-Workloads erstellten und entfernten ständig eine große Anzahl von kurzlebigen Datenstrukturen. ** Eine verzögerte Hintergrundsynchronisierung:** Ein Daten-Synchronisierungsprozess war weit zurückgefallen, was die Datenbank daran hinderte, nach sich selbst aufzuräumen. Der Wartungsprozess verlangsamte sich und endete schließlich. Die Datenbank konnte dann keine neuen Daten mehr speichern, und Anfragen begannen sich in die Warteschlange zu stellen. Unsere Dienste wiederholten diese Anfragen und eröffneten viele neue Verbindungen, die die Verbindungskapazität der Datenbank verbrauchten. Kunden sahen dies als Fehler und langsame Reaktionen. Wir wechselten zu unserer Standby-Datenbank. Bevor es den Verkehr bedienen konnte, musste es alle Änderungen seit dem letzten abgeschlossenen Wartungszyklus, etwa vier Stunden Aktivität, verarbeiten. Das verlängerte den Ausfall. **4 ergriffene Maßnahmen** • Reduzierte Belastung der Datenbank durch vorübergehende Herunterskalierung nicht wesentlicher Verarbeitung. • Es wurde ein Wechsel zur Standby-Datenbank gestartet. • Eröffnete einen Supportfall mit unserem Cloud-Infrastrukturanbieter und arbeitete mit ihnen auf eskalierter Basis zusammen. • Parallel einen alternativen Wiederherstellungspfad vorbereitet. • Teilen Sie einen temporären Workaround für Kunden, der durch die erforderlichen Pull-Request-Checks blockiert wurde. • Sobald die Datenbank wiederhergestellt wurde, erhöhte sich die Verarbeitungskapazität, um verzögerte Ereignisse zu löschen.

12. 7. Oktober 2026 um 14:22 UTCinvestigating

    Der letzte verbleibende Rückstand wird weiterhin konstant verarbeitet. Unsere Schätzungen zeigen, dass der Rückstand der letzten Teile in etwa 60-90 Minuten (20:30 UTC) vollständig verarbeitet werden sollte. Wir sehen, dass die meisten Pull-Request-Scans (60% zum Zeitpunkt dieses Updates) in weniger als 15 Minuten abgeschlossen sind. Und diese Zahl wächst stetig. Abgesehen davon sieht dieses System funktionsfähig aus. Wir glauben, dass Anwendung / Benutzeroberfläche voll funktionsfähig sind.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 5. Oktober 2026 um 13:24 UTCinvestigating

   Wir haben eine verschlechterte Leistung in prod-us festgestellt Flows wie Pull Request oder CLI-Scanning können langsamer als üblich sein

2. 5. Oktober 2026 um 14:17 UTCinvestigating

   Wir untersuchen weiterhin eine erhebliche Verschlechterung der US-Plattform, die durch die Erschöpfung der PostgreSQL-Verbindung verursacht wird. Kunden können langsame Reaktionszeiten, erhöhte 500-Fehler und langsamere PR-Workflows und CLI-Scans erleben. Wir haben die Datenbankbelastung für mehrere Dienste reduziert und ein RDS-Failover initiiert. Das Team arbeitet aktiv daran, die normale Leistung wiederherzustellen.

3. 5. Oktober 2026 um 14:29 UTCinvestigating

   Das Team arbeitet aktiv mit AWS zusammen und untersucht, was ein Failover-Problem mit Datenbanken zu sein scheint, das die US-Umgebung beeinflusst. Wir werden ein weiteres Update teilen, sobald wir mehr Informationen haben.

4. 5. Oktober 2026 um 15:17 UTCinvestigating

   Das Team arbeitet weiterhin mit AWS zusammen, was das Problem intern eskaliert hat. Parallel dazu arbeiten wir daran, die Funktionalität wiederherzustellen, indem wir in eine andere Datenbank wechseln. Alle blockierten Pull-Anfragen, die auf den Cycode-Status warten, können freigegeben werden, indem Cycode-Scans aus den erwarteten Prüfungen direkt in Ihrem SCM (Source Code Management) entfernt werden. Wenden Sie sich an Ihren Cycode-Vertreter, um den Prozess zu optimieren.

5. 5. Oktober 2026 um 16:10 UTCinvestigating

   AWS hat bestätigt, dass sich die betroffene PostgreSQL-Instanz derzeit in einem internen Wiederherstellungszustand befindet. Der erwartete Multi-AZ-Failover fand nicht wie geplant statt, und AWS untersucht aktiv, warum. Parallel dazu arbeiten wir weiter daran, die betroffenen Dienste mit einem alternativen Datenbankpfad wiederherzustellen, um die Wiederherstellung zu beschleunigen

6. 5. Oktober 2026 um 16:58 UTCinvestigating

   Wir sehen, dass die Datenbank ihre operativen Kapazitäten wiederherstellt. Wir sehen, dass erste Pull Request Scans verarbeitet werden. Wir überwachen das System und erhöhen den Durchsatz.

7. 5. Oktober 2026 um 17:31 UTCinvestigating

   Die Datenbank bleibt voll funktionsfähig. Wir arbeiten daran, die Verarbeitungsgeschwindigkeit über die reguläre hinaus zu erhöhen, um alle Backlogs so schnell wie möglich zu verarbeiten.

8. 5. Oktober 2026 um 18:17 UTCinvestigating

   Die US-Plattform verbessert sich nach der früheren Erschöpfung der RDS/PostgreSQL-Verbindung. AWS hat bestätigt, dass die ursprüngliche PostgreSQL-Instanz in einen Betriebszustand zurückgekehrt ist, und wir sehen, dass PR-Scans erneut verarbeitet werden. Der größte verbleibende Abbau ist die verzögerte GitHub-gesteuerte Verarbeitung aufgrund eines großen Webhook-Backlogs, der weiterhin abläuft. Wir werden die Wiederherstellung weiterhin überwachen und ein weiteres Update bereitstellen, wenn die Verarbeitung wieder normal wird

9. 5. Oktober 2026 um 19:06 UTCinvestigating

   Der letzte verbleibende Rückstand wird weiterhin konstant verarbeitet. Unsere Schätzungen zeigen, dass der Rückstand der letzten Teile in etwa 60-90 Minuten (20:30 UTC) vollständig verarbeitet werden sollte. Wir sehen, dass die meisten Pull-Request-Scans (60% zum Zeitpunkt dieses Updates) in weniger als 15 Minuten abgeschlossen sind. Und diese Zahl wächst stetig. Abgesehen davon sieht dieses System funktionsfähig aus. Wir glauben, dass Anwendung / Benutzeroberfläche voll funktionsfähig sind.

10. 5. Oktober 2026 um 20:09 UTCinvestigating

    Das System ist wieder voll funktionsfähig

11. 5. Oktober 2026 um 20:24 UTCresolved

    **1. Zusammenfassung** Am 5. Oktober 2026, ab 15:55 Uhr IDT, sahen Kunden auf unserer US-Plattform langsame Antworten, intermittierende Fehler und Verzögerungen bei Pull-Request-Checks und CLI-Scans. Einige Kunden, deren Repositories Cycode Pull Request Checks erfordern, konnten nicht zusammengeführt werden, bis das Scannen wieder aufgenommen wurde. Das Problem begann, als ein Hintergrundwartungsprozess in unserer primären Datenbank zurückfiel und nicht mehr abgeschlossen wurde und die Datenbank keine neuen Daten mehr speicherte. Der Restaurierungsservice dauerte mehrere Stunden, da die Standby-Datenbank zunächst einen großen Änderungsbestand verarbeiten musste. Die Datenbank war zurück und die Plattform war bis 19:43 IDT wieder verfügbar. Die verzögerte Verarbeitung holte dann auf und der Vorfall wurde um 23:24 IDT behoben. Pull-Anfragen, die während des Vorfalls verpasst wurden, wurden gescannt. **2. Key Timeline (IDT)** • **Oktober 5, 2026, 12:55 IDT**: Ein routinemäßiger Datenbankwartungsprozess beginnt viel langsamer als normal. Noch keine Kundenauswirkungen. • **Oktober 5, 2026, 14:53 IDT**: Der nächste Wartungszyklus beginnt und wird nicht abgeschlossen. • **Oktober 5, 2026, 15:55 IDT**: Die Datenbank stoppt das Speichern neuer Daten und die Plattformleistung verschlechtert sich. • **Oktober 5, 2026, 16:03 IDT**: Die Datenbank erreicht ihre Verbindungsgrenze. Kunden beginnen Fehler zu sehen. • **Oktober 5, 2026, 16:21 IDT**: Vorfall erklärt und Reaktionsteam engagiert. • **Oktober 5, 2026, 16:24 IDT**: Erstes Update auf der Statusseite. • **Oktober 5, 2026, 16:49 IDT**: Wechseln Sie zur Standby-Datenbank gestartet. • **Oktober 5, 2026, 17:00 IDT**: Der Supportfall wurde mit unserem Cloud-Infrastrukturanbieter eröffnet. • **Oktober 5, 2026, 18:24 IDT**: Der alternative Wiederherstellungspfad begann parallel. Workaround für Kunden veröffentlicht, die durch erforderliche Pull Request Checks blockiert wurden. • **Oktober 5, 2026, 19:43 IDT**: Datenbank wieder verfügbar, und die Cycode API und Cycode Platform sind zugänglich. • **Oktober 5, 2026, 19:54 IDT**: Pull Request Scanning Lebensläufe. • **Oktober 5, 2026, 20:20 IDT**: Die Verarbeitungskapazität wurde erhöht, um verzögerte Ereignisse zu löschen. • **Oktober 5, 2026, 20:45 IDT**: Hochvolumige Workloads wurden angehalten, um die Datenbanklast zu reduzieren. • **Oktober 5, 2026, 21:56 IDT**: Pull-Anfragen, die während des identifizierten und gescannten Vorfalls verpasst wurden. • **Oktober 5, 2026, 23:09 IDT**: Alle Dienste sind voll funktionsfähig. • **Oktober 5, 2026, 23:24 IDT**: Vorfall behoben. **3. Wurzelursache** Unsere Datenbank führt einen routinemäßigen Hintergrundprozess durch, der regelmäßig aktuelle Änderungen an der dauerhaften Speicherung speichert. Zwei Bedingungen trugen dazu bei, dass sich dieser Prozess verlangsamte: • **Hochvolumige kurzlebige Datenoperationen:** Einige unserer Verarbeitungs-Workloads erstellten und entfernten ständig eine große Anzahl von kurzlebigen Datenstrukturen. ** Eine verzögerte Hintergrundsynchronisierung:** Ein Daten-Synchronisierungsprozess war weit zurückgefallen, was die Datenbank daran hinderte, nach sich selbst aufzuräumen. Der Wartungsprozess verlangsamte sich und endete schließlich. Die Datenbank konnte dann keine neuen Daten mehr speichern, und Anfragen begannen sich in die Warteschlange zu stellen. Unsere Dienste wiederholten diese Anfragen und eröffneten viele neue Verbindungen, die die Verbindungskapazität der Datenbank verbrauchten. Kunden sahen dies als Fehler und langsame Reaktionen. Wir wechselten zu unserer Standby-Datenbank. Bevor es den Verkehr bedienen konnte, musste es alle Änderungen seit dem letzten abgeschlossenen Wartungszyklus, etwa vier Stunden Aktivität, verarbeiten. Das verlängerte den Ausfall. **4 ergriffene Maßnahmen** • Reduzierte Belastung der Datenbank durch vorübergehende Herunterskalierung nicht wesentlicher Verarbeitung. • Es wurde ein Wechsel zur Standby-Datenbank gestartet. • Eröffnete einen Supportfall mit unserem Cloud-Infrastrukturanbieter und arbeitete mit ihnen auf eskalierter Basis zusammen. • Parallel einen alternativen Wiederherstellungspfad vorbereitet. • Teilen Sie einen temporären Workaround für Kunden, der durch die erforderlichen Pull-Request-Checks blockiert wurde. • Sobald die Datenbank wiederhergestellt wurde, erhöhte sich die Verarbeitungskapazität, um verzögerte Ereignisse zu löschen. • Unterbrach die Workloads, die hohe Mengen an kurzlebigen Datenoperationen verursachten, um die Datenbanklast zu reduzieren, während verzögerte Ereignisse gelöscht wurden. • Scannen der Pull-Anfragen, die während des Vorfalls verpasst wurden. **4b. Aktionspunkte** • Ändern Sie, wie große Datenchargen geschrieben werden, um die Datenbanklast zu reduzieren. • Verschieben Sie unsere volumenstärkste Workload in eine eigene dedizierte Datenbank, so dass ein Problem dort den Rest der Plattform nicht beeinflussen kann. • Hinzufügen von Benachrichtigungen und einer tieferen Überwachung der Nutzung der Datenbankverbindung und des Datenbankzustands. • Geben Sie jedem Dienst seine eigenen dedizierten Datenbankanmeldeinformationen. • Verarbeiten Sie eingehende Ereignisse effizienter, um die Wiederherstellung nach einer Störung zu beschleunigen. • Verbesserte Überwachung von Verarbeitungsverzögerungen und internen Ereigniswarnungen. • Überprüfen Sie die Datenbankkapazitäts- und Leistungseinstellungen, um mehr Headroom hinzuzufügen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 14:14 UTCmonitoring

   Um 14:00 Uhr EDT (18:00 UTC) identifizierten wir eine signifikante Ladespitze, die die Authentifizierungsdatenbank beeinflusste. Um das Problem zu beheben, haben wir ein Instanz-Upgrade durchgeführt. Eine kurze Unterbrechung der Datenbankverbindungen kann während des Upgrades aufgetreten sein. Die Plattform ist stabil und wir beobachten die Situation weiterhin genau.

2. 7. Oktober 2026 um 14:14 UTCresolved

   Das System ist voll funktionsfähig, ohne dass laufende Probleme beobachtet werden. Dieser Vorfall ist nun gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. September 2026 um 19:08 UTCmonitoring

   Um 14:00 Uhr EDT (18:00 UTC) identifizierten wir eine signifikante Ladespitze, die die Authentifizierungsdatenbank beeinflusste. Um das Problem zu beheben, haben wir ein Instanz-Upgrade durchgeführt. Eine kurze Unterbrechung der Datenbankverbindungen kann während des Upgrades aufgetreten sein. Die Plattform ist stabil und wir beobachten die Situation weiterhin genau.

2. 28. September 2026 um 20:45 UTCresolved

   Das System ist voll funktionsfähig, ohne dass laufende Probleme beobachtet werden. Dieser Vorfall ist nun gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 14:14 UTCresolved

   Aufgelöst

2. 7. Oktober 2026 um 14:14 UTCinvestigating

   GitHub-Komponente: Pull Requests Original GitHub Incident:

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 08:42 UTCinvestigating

   GitHub-Komponente: Pull Requests Original GitHub Incident:

2. 8. Oktober 2026 um 08:42 UTCresolved

   Aufgelöst

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. September 2026 um 10:36 UTCinvestigating

   GitHub-Komponente: Pull Requests Original GitHub Incident:

2. 13. September 2026 um 18:53 UTCresolved

   Aufgelöst

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 14:04 UTCresolved

   MemoryDB-Metriken sind stabil, die Verarbeitungsverzögerung hat sich erholt und das System ist jetzt voll funktionsfähig.

2. 7. Oktober 2026 um 14:04 UTCmonitoring

   Wir haben einen starken Anstieg der MemoryDB-Speicherauslastung bei Prod-US beobachtet, einschließlich der aktiven Swap-Nutzung. Mitigation wurde angewendet. MemoryDB-Metriken sind seitdem stabil geblieben, und die Verarbeitungsverzögerung nimmt schnell ab

3. 7. Oktober 2026 um 14:04 UTCinvestigating

   Wir haben eine verschlechterte Leistung in prod-us festgestellt Flows wie Pull Request oder CLI-Scanning können langsamer als üblich sein

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. September 2026 um 16:53 UTCinvestigating

   Wir haben eine verschlechterte Leistung in prod-us festgestellt Flows wie Pull Request oder CLI-Scanning können langsamer als üblich sein

2. 8. September 2026 um 17:21 UTCmonitoring

   Wir haben einen starken Anstieg der MemoryDB-Speicherauslastung bei Prod-US beobachtet, einschließlich der aktiven Swap-Nutzung. Mitigation wurde angewendet. MemoryDB-Metriken sind seitdem stabil geblieben, und die Verarbeitungsverzögerung nimmt schnell ab

3. 8. September 2026 um 17:26 UTCresolved

   MemoryDB-Metriken sind stabil, die Verarbeitungsverzögerung hat sich erholt und das System ist jetzt voll funktionsfähig.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 14:14 UTCinvestigating

   Wir haben eine verschlechterte Leistung in prod-eu festgestellt. Die Leistungsverschlechterung wirkt sich auf alle Anwendungen aus und alle Flüsse (**wie Pull Request oder CLI-Scanning**) können langsamer als üblich sein. Unsere ersten Untersuchungen deuten auf eine übermäßige Belastung der gemeinsamen Datenbank hin, wodurch das Lesen und Schreiben langsamer wird. Das Team untersucht weiter.

2. 7. Oktober 2026 um 14:14 UTCresolved

   Das System ist wieder voll funktionsfähig.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. September 2026 um 09:53 UTCinvestigating

   Wir haben eine verschlechterte Leistung in prod-eu festgestellt. Die Leistungsverschlechterung wirkt sich auf alle Anwendungen aus und alle Flüsse (**wie Pull Request oder CLI-Scanning**) können langsamer als üblich sein. Unsere ersten Untersuchungen deuten auf eine übermäßige Belastung der gemeinsamen Datenbank hin, wodurch das Lesen und Schreiben langsamer wird. Das Team untersucht weiter.

2. 8. September 2026 um 10:52 UTCresolved

   Das System ist wieder voll funktionsfähig.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 14:14 UTCresolved

   GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/0xbhhq84v4mt

2. 7. Oktober 2026 um 14:14 UTCinvestigating

   GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/0xbhhq84v4mt

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 08:42 UTCinvestigating

   GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/0xbhhq84v4mt

2. 8. Oktober 2026 um 08:42 UTCresolved

   GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/0xbhhq84v4mt

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. September 2026 um 15:10 UTCinvestigating

   GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/0xbhhq84v4mt

2. 1. September 2026 um 16:05 UTCresolved

   GitHub-Komponente: Pull Requests Ursprünglicher GitHub-Vorfall: https://stspg.io/0xbhhq84v4mt

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 08:42 UTCinvestigating

   GitHub-Komponente: Pull Requests GitHub-Vorfall: https://stspg.io/nrbwjftcz72d

2. 8. Oktober 2026 um 08:42 UTCresolved

   GitHub-Komponente: Pull Requests GitHub-Vorfall: https://stspg.io/nrbwjftcz72d

Automatisch aus der offiziellen Störungsmeldung übersetzt.