Störungsverlauf von Stripo

1. 5. August 2026 um 13:59 UTCinvestigating

   We are aware of an issue with the Stripo Plugin: the editor may fail to initialize and does not load for end users. Our team has identified the affected service and is working on a fix. We will post an update as soon as we have more information.

2. 5. August 2026 um 14:00 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 5. August 2026 um 14:49 UTCmonitoring

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

4. 5. August 2026 um 14:57 UTCresolved

   This incident has been resolved.

5. 5. August 2026 um 16:03 UTCpostmortem

   At 13:45 UTC the AWS host running the database and cache for our plugin environment failed. Auto-recovery restarted it by 14:00 UTC, but the cache service and several microservices required manual restarts. Full recovery: ~15:00 UTC. **Impact \(UTC\).** Autosave was unavailable 13:48–13:57, then severely slow \(~86 s per request vs. under 7 s normally\) until ~14:40. Some plugins using external AutoSave callbacks saw saves fail. Co-editing was degraded 14:16–15:00. Editor initialization also failed for some users early on. **Data.** No evidence of loss: crash recovery completed correctly, all patches that reached the database were persisted, and duplicate resubmissions were safely rejected. Contact us with a timestamp if you suspect otherwise. **Cause.** Hardware failure on the underlying AWS host. It escalated because autosave retries external callbacks synchronously inside the request, exhausting the database connection pool; the cache had no auto-start on reboot; and connection pools did not self-heal. No alarm covered host status or cache availability, so detection came from user reports. **Fixes.** Alerting on host status checks and cache availability; cache auto-start with a health check; connection pool recovery; moving external callbacks out of the request path; alerts on pool saturation, error rate and callback latency; a redundancy review for this environment. We apologize for the disruption. If the impact on your users differed from the above, please contact our support team.

1. 31. Juli 2026 um 08:30 UTCinvestigating

   Wir untersuchen Berichte über Benutzer, die sich nicht anmelden können, vermisste Teammitglieder sehen oder langsames Laden von E-Mails erleben. Unser Team arbeitet daran, die Ursache zu identifizieren.

2. 31. Juli 2026 um 08:30 UTCidentified

   Wir haben die Ursache identifiziert: Ein interner Caching-Service (Redis) hatte keinen Speicher mehr und begann, Schreiben abzulehnen. Infolgedessen haben Berechtigungsprüfungen den Cache umgangen und den Kontodienst übermäßig belastet, was zu langsamen Reaktionen, Anmeldefehlern und fehlenden Kontodaten führte. Wir haben die Cache-Kapazität erhöht und bereiten einen permanenten Fix vor.

3. 31. Juli 2026 um 08:31 UTCmonitoring

   Die Cache-Kapazität wurde erhöht und das System erholt sich. Die Reaktionszeiten werden wieder normal, wenn sich die Caches aufwärmen. Ein permanenter Fix wird bereitgestellt.

4. 31. Juli 2026 um 08:49 UTCresolved

   Der permanente Fix wurde für alle Produktionscluster bereitgestellt und alle Systeme funktionieren normal. Während des Vorfalls (30. Juli, 22:48 UTC - 31. Juli, ~04:30 UTC, mit Restlangsamkeit bis ~08:49 UTC) traten bei einigen Benutzern Anmeldefehler, fehlende Teamdaten und das langsame Laden von E-Mails auf. Es gingen keine Daten verloren. Wir haben eine Speicherbenutzungswarnung hinzugefügt, um diese Problemklasse zu erkennen, bevor sie Benutzer betrifft. Wir entschuldigen uns für die Unannehmlichkeiten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. Juli 2026 um 14:02 UTCresolved

   Am 28. Juli, zwischen etwa 1:28 Uhr und 1:58 Uhr (UTC), konnte das Stripo Plugin nicht für eingebettete Integrationen initialisiert werden. Das Problem wurde durch die verschlechterte Leistung eines internen Statistikdienstes verursacht, was die Initialisierungsanforderungen für Plugins verlangsamte. Unser Team hat den betroffenen Dienst neu gestartet und die Statistiksammlung für Plugin-Initialisierungen vorübergehend deaktiviert, um den normalen Betrieb wiederherzustellen. Das Plugin wird nun wie erwartet geladen. Wir entschuldigen uns für alle Unannehmlichkeiten, die dies verursacht haben könnte.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. Juli 2026 um 09:18 UTCinvestigating

   Es kann Probleme beim Hochladen, Ändern oder Entfernen von Kundenbildern im Editor geben. Zeit (UTC) : 2026-07-25T09:18:22

2. 25. Juli 2026 um 09:20 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juli 2026 um 11:27 UTCresolved

   Am 24. Juli zwischen 09:20 und 09:50 UTC war das Echtzeit-Co-Editing im Plugin-Editor vorübergehend nicht verfügbar. Während eines geplanten Releases dauerte eine Aktualisierung des Datenbankschemas länger als erwartet und überlastete die Datenbank kurzzeitig, wodurch der Co-Editing-Dienst neu gestartet wurde. Unser Team identifizierte die Ursache und stellte den Service bis 09:50 UTC vollständig wieder her. Es gingen keine Kundendaten verloren und alle anderen Stripo-Funktionalitäten blieben durchgehend verfügbar. Seitdem haben wir unserem Release-Prozess Sicherheitsvorkehrungen hinzugefügt, um eine Wiederholung zu verhindern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Juli 2026 um 09:39 UTCinvestigating

   Möglicherweise gibt es ein Problem mit dem Zugriff auf das Konto des Kunden. Zeit (UTC) : 2026-07-23T09:39:04

2. 23. Juli 2026 um 09:49 UTCinvestigating

   [Kommentar von Opsgenie]Dmitry Kudrenko bestätigte Warnung: "Teilweiser Ausfall in der Arbeit des Stripo Account Backend-Teils"

3. 23. Juli 2026 um 10:02 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 20. Juli 2026 um 18:11 UTCinvestigating

   Stripo Sicherheitsvorfall Wie das begann Wir haben zwei Kundenberichte über ungewöhnliche Aktivitäten im Zusammenhang mit ESP-Konten erhalten. Während ein einzelner Bericht vernünftigerweise auf eine Vielzahl von Ursachen zurückzuführen sein könnte, einschließlich Konfigurationsproblemen, Legacy-Integrationen oder anbieterspezifischen Faktoren, betraf der zweite Bericht einen anderen ESP-Anbieter und wies ähnliche Merkmale auf. Zu diesem Zeitpunkt stellten wir fest, dass das beobachtete Muster eine umfassende Sicherheitsüberprüfung erforderte, und leiteten eine umfassendere Untersuchung ein. Aktueller Status Als wir Konten mit gespeicherten ESP-Anmeldeinformationen identifizierten, baten wir diese Kunden, ihre Schlüssel vorrangig zu drehen. Dies war kein einziger, vollständiger Pass: Als unsere Untersuchung fortgesetzt wurde, identifizierten wir zusätzliche Konten, die die gleiche Benachrichtigung erforderten, und wir haben sie kontaktiert, als sie bestätigt wurden. Wenn Sie ESP-Anmeldeinformationen mit Stripo verbunden haben und diese noch nicht gedreht haben: 1. Entfernen Sie den alten Schlüssel dort; die Generierung eines neuen Schlüssels deaktiviert den alten nicht automatisch. 2. Generieren Sie einen neuen Schlüssel in Ihrem ESP-Konto. 3. Aktualisieren Sie den neuen Schlüssel in Stripo unter Projekteinstellungen → Integrationen. 4. Überprüfen Sie die letzten Aktivitäten Ihres ESP- oder CRM-Kontos: Anmeldeverlauf, Änderungen der Kontaktliste und alle Kampagnen oder Sendungen, die Sie nicht erkennen. Eine Erinnerung, während all dies im Gange ist: Wir werden Sie niemals bitten, einen Schlüssel, ein Token oder ein Passwort per E-Mail oder in einem Support-Chat zu senden. Laufende Untersuchung Unsere Ermittlungen gehen weiter. Sollten wir bestätigte Erkenntnisse identifizieren, die für betroffene Kunden wesentlich sind, werden wir diese unverzüglich mitteilen.

2. 20. Juli 2026 um 18:15 UTCinvestigating

   Jul 20, 2026 - 18:15 UTC Was wir repariert haben Nach unserer ersten Kommunikation haben wir eine Reihe zusätzlicher Sicherheitsverbesserungen implementiert: 1. Prüfung des Vertrauensschutzes . Wir haben überprüft, wie Anmeldeinformationen in unseren Systemen gespeichert werden, und zusätzliche Verschlüsselung für Anmeldedaten implementiert, bei denen ein verbesserter Schutz als angemessen identifiziert wurde. 2. Implementierung zusätzlicher browserseitiger Schutzmaßnahmen zur Bewältigung eines identifizierten browserbezogenen Expositionsszenarios. Gespeicherte Anmeldeinformationen werden beim Öffnen des Integrationsbildschirms nicht mehr an den Browser zurückgesendet. Dies, kombiniert mit der oben genannten Speicherverbesserung, reduziert die potenziellen Expositionsrisiken im Zusammenhang mit dem Umgang mit Anmeldeinformationen erheblich. 3. Abschluss eines vollständigen Logging-Audits. Wir haben unsere Logging-Systeme Ende-zu-Ende überprüft und unsere Logging-Konfiguration aktualisiert, um zu verhindern, dass Anmeldewerte in Anwendungsprotokollen aufgezeichnet werden. 4. Bereinigung veralteter Daten . Wir haben alte ESP-Verbindungen gelöscht, die beibehalten wurden, nachdem sie nicht mehr verwendet wurden, und wir sind dabei, alte, nicht verwendete Schlüssel zu entfernen. Aufgrund unserer bisherigen Untersuchung haben wir keine Hinweise auf Auswirkungen auf das Stripo Plugin festgestellt. Stripo speichert keine Finanz- oder Zahlungsinformationen der Kunden. Dementsprechend haben wir auf der Grundlage unserer bisherigen Untersuchung keine Auswirkungen auf die von Stripo gepflegten Finanz- oder Zahlungsdaten festgestellt. Basierend auf den derzeit verfügbaren Informationen haben wir keine Auswirkungen auf unsere primären Produktionssysteme festgestellt. Die bisher identifizierte Aktivität scheint mit einer Backup-Umgebung verknüpft zu sein. Wir haben zusätzliche Sicherheitsmaßnahmen für diese Umgebung implementiert und prüfen weiterhin, ob es im Rahmen unserer laufenden Untersuchung größere Auswirkungen gibt. Konformitätsbescheinigungen Wir unterhalten ein unabhängig geprüftes Sicherheitsprogramm, einschließlich SOC 2 und ISO-Zertifizierungen. Im Rahmen dieser Untersuchung identifizierten wir Möglichkeiten, bestimmte technische Kontrollen im Zusammenhang mit dem Umgang mit Exportzertifikaten weiter zu verstärken. Wir haben zusätzliche Sicherheitsvorkehrungen getroffen, um die während unserer Untersuchung identifizierten Angelegenheiten anzugehen. Wir integrieren die Ergebnisse dieser Untersuchung auch in unser Sicherheitsprogramm, unsere Risikobewertungsprozesse, technische Kontrollen und zukünftige Auditaktivitäten. Diese Erkenntnisse haben zusätzliche technische Sicherheitsvorkehrungen getroffen und werden weiterhin in unser Sicherheitskontrollen- und Auditprogramm aufgenommen. Sicherheitszertifizierungen zeigen, dass das Sicherheitsprogramm einer Organisation unabhängig anhand anerkannter Standards bewertet wurde. Wie jedes Sicherheits-Framework unterstützen sie die kontinuierliche Verbesserung, da neue Risiken und Implementierungsüberlegungen identifiziert werden. Laufende Untersuchung Unsere Ermittlungen gehen weiter. Im Rahmen dieser Arbeit überprüfen wir weiterhin die Zugriffsaktivitäten in Bezug auf die Datenbankinstanzen, in denen die relevanten Daten gespeichert sind. Sollten wir bestätigte Erkenntnisse identifizieren, die für betroffene Kunden von wesentlicher Bedeutung sind, werden wir diese unverzüglich mitteilen.

3. 21. Juli 2026 um 14:23 UTCresolved

   Vorfall Zeitraum: 6-18 Juli 2026 · Veröffentlicht: 21. Juli 2026 Final Incident Report — Unbefugter Zugriff auf gespeicherte Integrationsanmeldeinformationen Zusammenfassung Zwischen dem 6. und 18. Juli 2026 erhielt ein nicht autorisierter Akteur Zugang zu einer internen, nicht kundenorientierten Umgebung, die Lesezugriff auf eine eingeschränkte, schreibgeschützte Replik mit einer begrenzten Teilmenge von Produktionsdaten hatte. Auf der Grundlage unserer abgeschlossenen Untersuchung führte der Akteur Leseanfragen aus, die zu einem Zugriff auf bestimmte in dieser Umgebung gespeicherte Informationen führten, einschließlich bestimmter ESP-/Exportdaten von Drittanbietern, die Kunden für ihre Integrationen in Stripo gespeichert hatten, zusammen mit bestimmten Kontodatensätzen. Nachdem wir die Aktivität identifiziert hatten, haben wir die betroffene Umgebung isoliert und stillgelegt, Sanierungsmaßnahmen ergriffen und unsere Untersuchung des Vorfalls abgeschlossen. Der Vorfall wurde ausschließlich durch eine Kundenanfrage gemeldet und konnte durch unsere Standardüberwachung nicht erkannt werden. Welche Daten betroffen waren Auf der Grundlage unserer abgeschlossenen Untersuchung enthielten die Informationen, auf die zugegriffen wurde, bestimmte ESP-/Exportdaten von Drittanbietern, die Kunden für die Verbindung ihrer Integrationen gespeichert hatten, zusammen mit bestimmten zugehörigen Kontodaten. Kontoauthentifizierungsdaten. Stripo-Passwörter werden gehasht und gesalzen gespeichert - niemals im Klartext, im Einklang mit den bewährten Sicherheitspraktiken, so dass sie nicht in einer verwendbaren Form ausgesetzt wurden. Da ein entschlossener Angreifer theoretisch versuchen könnte, gesalzene Hashes im Laufe der Zeit zu knacken, haben wir kein Risiko eingegangen: Wir haben jedes Stripo-Passwort proaktiv zurückgesetzt, obwohl es keinen Hinweis darauf gibt, dass die Hashes praktisch wiederhergestellt werden können. Jeder Nutzer legt bei seiner nächsten Anmeldung einfach ein neues Passwort fest. Was wir getan haben 1. Eindämmung des Vorfalls durch Abschaltung und Stilllegung der betroffenen internen Umgebung. 2. Erweiterte Verschlüsselung im Ruhezustand auf alle gespeicherten ESP/Export-Anmeldeinformationen, einschließlich derjenigen, die nicht bereits verschlüsselt waren (Schlüssel in einem verwalteten AWS KMS). 3. Stoppte die Rückgabe von Anmeldeinformationen an den Browser, wenn Integrationsbildschirme geöffnet werden. 4. Überprüfung der Anwendungsprotokollierung und Entfernung von Anmeldewerten aus den begrenzten Szenarien, in denen sie auftreten könnten. Während unsere Untersuchung keine Beweise dafür ergab, dass Anwendungsprotokolle Teil des Angriffspfades waren, haben wir diese zusätzliche Absicherung dennoch als Teil unserer umfassenderen Sanierungsbemühungen implementiert. 5. Gereinigte alte/inaktive Anmeldeinformationen, die nach ihrer Nichtnutzung beibehalten wurden. 6. Für Klavio, HubSpot, Zoho und AWeber haben wir automatisch alle Autorisierungstoken widerrufen. 7. Durchführung einer vollständigen Überprüfung in unserem Infrastrukturbereich: Prüfung aller Sicherheitsgruppen und Zugangspfade zu Systemknoten, Rotation der Passwörter für alle Datenbanken, Beschränkung des Read-Only-Replikats auf internen Zugriff und Überprüfung des Zugriffs durch interne Dienste und Mitarbeiter, Verschärfung nach den Grundsätzen der Mindestprivilegien. 8. Setzen Sie proaktiv alle Benutzerpasswörter und ungültigen Sitzungen zurück. 9. Zusätzliche Überwachung und Alarmierung zur Authentifizierung für interne Tools, externe Datenbankverbindungen und Massenlesungen sensibler Tabellen. Wir arbeiten unter anerkannten Sicherheits- und Datenschutzstandards, einschließlich unseres SOC 2-Programms. Im Rahmen unseres laufenden Sicherheitsprogramms verstärken wir weiterhin unsere technischen und organisatorischen Kontrollen auf der Grundlage der Ergebnisse dieser Untersuchung. Wer nicht betroffen war Kunden, die nur in Dateiformate (HTML, AMP HTML, PDF, EML, Bild, etc.) exportiert haben, haben bei uns nie Anmeldeinformationen gespeichert und sind nicht betroffen. Anmeldeinformationen wurden auch nicht für die folgenden Anbieter abgerufen: CleverTap, Customer.io, Follow Up Boss, Google Cloud, MailerCloud, MailerLite, Mailtrap, Make, Mindbaz, n8n, Netcore, OneSignal, Optimove, Postup, Pubrio, Rapidmail, Reteno, Selzy, Sender.net, Ticketor, Unione, Insider, Voizee, WhatCounts, Yespo. Plugin und Self-Hosted-Bereitstellungen waren nicht betroffen – die Umgebung und die Replika sind Teil der Stripo Cloud-Infrastruktur, nicht das Self-Hosted-Produkt oder das Stripo-Plugin. Langinaktive Konten. Im Rahmen unserer Datenspeicherung und im Einklang mit unseren DSGVO-Verpflichtungen werden inaktive Kundenkonten und deren personenbezogene Daten routinemäßig gelöscht, so dass Informationen von lang inaktiven Kunden in diesem Umfeld nicht vorhanden waren und nicht hätten offengelegt werden können. Zahlungsdaten Aufgrund unserer Untersuchung wurden keine vollständigen Zahlungskartennummern (PANs) oder CVV-Codes als zugegriffen identifiziert. Kartenzahlungen werden von unseren Zahlungsanbietern (Stripe und PayPal) verarbeitet, und Stripo speichert keine vollständigen Zahlungskartennummern oder CVV-Codes. Zusammenarbeit mit unseren ESP Partnern Da es sich um Anmeldeinformationen von Drittanbietern handelt, setzen wir uns im Geiste der Partnerschaft und zum Schutz unserer gemeinsamen Kunden proaktiv mit den beteiligten ESP-Anbietern in Verbindung, so dass die betroffenen Anmeldeinformationen von ihrer Seite als zusätzliche Sicherheit widerrufen werden können. Was wir unseren Kunden empfehlen 1. Wenn sich Ihr Provider nicht im Abschnitt „Wer war nicht betroffen befindet und Sie dies noch nicht getan haben: Drehen Sie die ESP-Anmeldeinformationen, die mit Ihrem Stripo-Konto verbunden sind – widerrufen Sie den alten Schlüssel bei Ihrem Provider, generieren Sie einen neuen und aktualisieren Sie ihn in Stripo (Projekteinstellungen → Integrationen). Für OAuth-basierte Integrationen widerrufen Sie die Autorisierung von Stripo bei Ihrem Provider und verbinden Sie sich erneut. 2. Überprüfen Sie Ihre ESP/CRM-Aktivität ab Anfang Juli – Anmeldungen, Kontaktlistenänderungen und alle Kampagnen, Sendungen oder Exporte, die Sie nicht erkennen. Durch das Drehen eines Schlüssels wird die zukünftige Nutzung gestoppt, aber die bereits aufgetretene Aktivität wird nicht rückgängig gemacht. 3. Ihr Stripo-Passwort wurde bereits zurückgesetzt - legen Sie bei Ihrer nächsten Anmeldung ein neues fest. Abschluss Wir bedauern aufrichtig, dass sich dieser Vorfall ereignet hat. Wir haben die betroffenen Kunden direkt kontaktiert und stehen Ihnen auf Anfrage weiterhin zur Verfügung, um Folgefragen zu beantworten. Kontakt: [email protected].

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Juli 2026 um 15:26 UTCinvestigating

   Es kann Probleme beim Hochladen, Ändern oder Entfernen von Kundenbildern im Editor geben. Zeit (UTC) : 2026-07-07T15:26:22

2. 7. Juli 2026 um 15:27 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 1. Juli 2026 um 03:53 UTCinvestigating

   Möglicherweise gibt es ein Problem im Zusammenhang mit dem Export von E-Mail-Vorlagen als PDF-Dateien aus dem Editor. Zeit (UTC): 2026-07-01T03:52:37

2. 1. Juli 2026 um 03:53 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 18. Juni 2026 um 13:43 UTCinvestigating

   Es kann Probleme beim Senden von Testnachrichten an bestimmte E-Mail-Adressen und/oder beim Testen von E-Mail-Vorlagen mit Email on Acid geben. Zeit (UTC) : 2026-06-18T13:43:15

2. 18. Juni 2026 um 13:44 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. Mai 2026 um 06:28 UTCinvestigating

   Es kann Probleme mit der Verwendung einer der Methoden der Public API geben. Zeit (UTC) : 2026-05-28T06:28:00

2. 28. Mai 2026 um 06:29 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 3. Mai 2026 um 07:18 UTCinvestigating

   Möglicherweise gibt es ein Problem mit dem Zugriff auf das Konto des Kunden. Zeit (UTC) : 2026-05-03T07:18:04

2. 3. Mai 2026 um 07:20 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. April 2026 um 02:03 UTCinvestigating

   Es kann Probleme beim Hochladen, Ändern oder Entfernen von Kundenbildern im Editor geben. Zeit (UTC) : 2026-04-28T02:02:57

2. 28. April 2026 um 02:05 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. April 2026 um 16:19 UTCinvestigating

   Es kann ein Problem im Zusammenhang mit der Wiedergabe von UI-Komponenten innerhalb des Kundenkontos geben. Zeit (UTC) : 2026-04-26T16:19:37

2. 26. April 2026 um 16:20 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. April 2026 um 08:11 UTCinvestigating

   Wir erleben derzeit erhöhte Reaktionszeiten im Plugin API Gateway, was sich auf die Geschwindigkeit und die Fähigkeit zur Initialisierung neuer Plugins auswirkt.

2. 22. April 2026 um 08:29 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 22. April 2026 um 08:30 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. April 2026 um 13:36 UTCinvestigating

   Wir erleben derzeit erhöhte Reaktionszeiten im Plugin API Gateway, was sich auf die Geschwindigkeit und die Fähigkeit zur Initialisierung neuer Plugins auswirkt.

2. 21. April 2026 um 13:51 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 21. April 2026 um 13:57 UTCresolved

   Das Problem mit erhöhten Reaktionszeiten im Plugin API Gateway wurde behoben und die Plugin-Initialisierung funktioniert jetzt normal. Ursache: Während eines geplanten AWS-Infrastruktur-Updates zum Anbringen von Patches, das ohne Ausfallzeiten erwartet wurde und daher nicht im Voraus kommuniziert wurde, trat eine unglückliche Fehlkonfiguration auf, die wir bereits identifiziert und behoben haben. Einige Pods wurden beendet, bevor neue vollständig fertig waren, was zu einer signifikanten Anhäufung von Anfragen in der Warteschlange führte. Anstatt schrittweise verarbeitet zu werden, wurde eine große Charge von Anfragen in der Warteschlange gleichzeitig bearbeitet, was die verfügbaren Datenbankverbindungen erschöpfte und zu Verzögerungen bei der Verarbeitung neuer eingehender Anfragen führte. Wir optimieren unsere Bereitstellungs- und Skalierungsverfahren, um ähnliche Situationen in Zukunft zu vermeiden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. April 2026 um 10:06 UTCresolved

   Am 8. April zwischen 09:51 UTC und 09:54 UTC erlebten wir eine kurze Service-Degradation, die sowohl die Stripo-Anwendung als auch das Plugin betraf. Das Problem wurde durch eine Fehlfunktion im AWS EKS Networking Stack (Amazon VPC CNI Addon) verursacht, der von AWS verwaltet wird und außerhalb unserer direkten Kontrolle liegt. Während dieser Zeit können Benutzer intermittierende Verbindungsprobleme auftreten. Der Vorfall wurde vollständig behoben und alle Dienste funktionieren normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. März 2026 um 07:10 UTCinvestigating

   Möglicherweise gibt es ein Problem mit dem Zugriff auf das Konto des Kunden. Zeit (UTC): 2026-03-29T07:10:04

2. 29. März 2026 um 07:12 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. März 2026 um 10:51 UTCinvestigating

   Möglicherweise gibt es ein Problem mit dem Zugriff auf das Konto des Kunden. Zeit (UTC): 2026-03-17T10:51:04

2. 17. März 2026 um 10:52 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. Februar 2026 um 08:49 UTCinvestigating

   Es kann Probleme beim Hochladen, Ändern oder Entfernen von Kundenbildern im Editor geben. Zeit (UTC) : 2026-02-26T08:48:57

2. 26. Februar 2026 um 08:49 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.