Störungsverlauf von Exalate

1. 27. August 2026 um 04:36 UTCinvestigating

   Atlassian hat derzeit ein Problem mit Jira und anderen Systemen - Details hier: https://status.atlassian.com/ Dies kann sich auf Ihre Exalate-Verbindungen auswirken, wenn Sie eine Verbindung zu einer Jira-Instanz herstellen.

2. 27. August 2026 um 04:44 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 27. August 2026 um 05:09 UTCmonitoring

   Atlassian hat eine Lösung gefunden, um das Problem zu lösen. Ihre Synchronisierung sollte bereits wieder normal sein, aber bitte wenden Sie sich im Falle von Problemen an den Support.

4. 27. August 2026 um 05:27 UTCresolved

   Alle Atlassian-Systeme sind wieder normal und die Synchronisation funktioniert wie erwartet. Im Falle von Problemen mit Ihrer Synchronisierung erstellen Sie bitte ein Support-Ticket und wir helfen Ihnen gerne weiter.

5. 8. September 2026 um 05:41 UTCpostmortem

   N/A

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juli 2026 um 06:12 UTCidentified

   Folge einer nicht angekündigten Änderung des Anwendungsnamens, die dazu führt, dass der Proxy-Benutzer mit dem vollständigen Namen der Anwendung angezeigt wird, anstatt nur "Exalate". Dies wurde Atlassian bereits mitgeteilt und wir warten auf die erforderlichen Maßnahmen, um die Änderung rückgängig zu machen. Auswirkung: Updates von Exalate zeigen "Exalate Classic Connector for Jira (Two-way Sync)" an, wenn der Benutzer die Änderung vornimmt.

2. 24. Juli 2026 um 09:15 UTCidentified

   Wir untersuchen weiterhin den besten Ansatz, um dieses Problem mit Hilfe der Atlassian-Unterstützung zu lösen.

3. 24. Juli 2026 um 12:39 UTCidentified

   Wir arbeiten aktiv mit Atlassian-Unterstützung zusammen, um so schnell wie möglich die beste Lösung für dieses Problem zu finden.

4. 24. Juli 2026 um 15:47 UTCidentified

   Wir arbeiten aktiv mit Atlassian-Unterstützung zusammen, um so schnell wie möglich die beste Lösung für dieses Problem zu finden. Wir werden das nächste Update innerhalb von 6 Stunden bereitstellen oder sobald uns relevante Informationen vorliegen.

5. 24. Juli 2026 um 16:33 UTCresolved

   Der Proxy-Benutzername wurde auf Exalate zurückgesetzt. Wir betrachten den Vorfall als gelöst.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 11:28 UTCinvestigating

   Einige Jira Cloud-Knoten erleben in den letzten 30 Minuten Instabilität. Das Problem ist begrenzt und betrifft nur einige Kunden. Wir werden in Kürze ein Update bereitstellen.

2. 16. Juli 2026 um 12:03 UTCidentified

   Wir werden eine Änderung an Exalate Cloud vornehmen, um die Stabilität zu verbessern. Die Auswirkungen auf Ihren Knoten werden auf einen Neustart beschränkt sein, bei dem der Knoten für einige Minuten nicht verfügbar ist. Die Unannehmlichkeiten werden bedauert.

3. 16. Juli 2026 um 13:38 UTCidentified

   Der rollende Neustart der Knoten ist im Gange. Sie werden einen kurzen Neustart auf JCloud-Knoten erleben. Wir werden Sie mit unseren Fortschritten auf dem Laufenden halten.

4. 16. Juli 2026 um 15:15 UTCidentified

   Der Neustart ist noch im Gange und geht ohne Probleme. Wir werden Sie aktualisieren, sobald es abgeschlossen ist.

5. 16. Juli 2026 um 15:57 UTCmonitoring

   Alle Knoten sind wieder im Normalbetrieb. Wir verfolgen die Situation weiterhin aufmerksam.

6. 16. Juli 2026 um 17:18 UTCresolved

   Nach genauer Überwachung gilt das Problem als vollständig gelöst. Wir werden hier zu gegebener Zeit eine RCA veröffentlichen.

7. 25. Oktober 2026 um 12:22 UTCpostmortem

   **Vorfall:** JiraCloud Nodes erleben Instabilität - 16. Juli 2026 **Dauer:** 12:28 CET – 16:57 CET \(ca. 4,5 Stunden\). Volle Stabilität bestätigt um 18:18 Uhr MEZ. **Auswirkungen:** Einige Jira Cloud-Integrationsknoten erlebten während dieses Fensters intermittierende Instabilität. Typischerweise ~10 Knoten wurden gleichzeitig betroffen. Die Problemsynchronisation auf nicht betroffenen Knoten lief weiterhin normal. Es gingen keine Daten verloren. **Zusammenfassung:** Am 16. Juli 2026 erlebten einige Jira Cloud-Integrationsknoten auf der Exalate Cloud-Plattform intermittierende Neustarts und Timeouts. Die Ursache war eine Ressourcenbeschränkung auf einem der zugrunde liegenden Hosting-Server. Ein zufälliges Software-Update richtete zunächst eine Untersuchung auf die Anwendungsschicht, aber eine umgebungsübergreifende Analyse bestätigte, dass Knoten auf anderen Infrastrukturen nicht betroffen waren - was das Problem auf einen einzigen Hosting-Server beschränkte. **Zeitleiste:** * 12:28 Uhr MEZ - Problem erkannt, Untersuchung eingeleitet * 13:03 Uhr MEZ - Stabilisierungsmaßnahmen ergriffen, rollender Neustart eingeleitet * 16:57 Uhr MEZ - Alle Knoten kehren zum Normalbetrieb zurück * 18:18 CET - Volle Stabilität bestätigt **Wurzelursache:** Ein Hosting-Server erreichte seine Ressourcenobergrenze aufgrund der konzentrierten Arbeitsbelastung während eines routinemäßigen Software-Update-Zyklus. Dies führte zu einem intermittierenden Ressourcenhunger für Knoten, die auf diesem Server ausgeführt werden. **Beschluss:** Die Arbeitslast wurde über die Hosting-Infrastruktur verteilt, um die Ressourcenauslastung auszugleichen. Alle betroffenen Knoten erholten sich ohne Datenverlust. **Vorbeugende Maßnahmen:** * Proaktive Alarmschwellen für die Nutzung von Infrastrukturressourcen wurden implementiert * Die Verteilung der Arbeitslast auf Hosting-Server wurde neu ausbalanciert, um Konzentration zu verhindern Wir entschuldigen uns für die Störung. Wir bleiben der Zuverlässigkeit der Exalate-Plattform verpflichtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Juli 2026 um 22:15 UTCinvestigating

   Wir haben mehrere Berichte über Synchronisierungen nach dem Update auf die neue Jira Cloud-Forge-App erhalten. Unsere erste untersuchung führt uns zu der annahme, dass dies aufgrund der Änderung des proxy-benutzerkontos geschieht. Wir arbeiten aktiv daran, die Ursache zu ermitteln und einen Fix anzuwenden.

2. 13. Juli 2026 um 23:48 UTCinvestigating

   Wir untersuchen dieses Problem weiterhin mit unseren Ingenieuren, um die Ursache zu ermitteln.

3. 14. Juli 2026 um 04:58 UTCidentified

   Die Ursache wurde identifiziert und wir arbeiten an einer Lösung. Bitte erwarten Sie innerhalb einer Stunde ein weiteres Update.

4. 14. Juli 2026 um 07:05 UTCidentified

   Der Fix wird derzeit validiert, um den besten Ansatz zu finden. Wir werden innerhalb einer Stunde ein weiteres Update bereitstellen.

5. 14. Juli 2026 um 08:11 UTCidentified

   Leider hat das Testen des Fixes ein unerwartetes Problem aufgedeckt und wir sind jetzt dabei, den Fix zu optimieren, um sicherzustellen, dass er alle möglichen Anwendungsfälle enthält. Wir werden in einer Stunde ein Update für Sie haben.

6. 14. Juli 2026 um 09:09 UTCidentified

   Der neue Fix wurde erstellt und erste Tests sind vielversprechend. Wir sind tief in QA mit dem neuen Fix und werden innerhalb einer Stunde ein Update über die Ergebnisse liefern. Die Unannehmlichkeiten werden bedauert.

7. 14. Juli 2026 um 10:11 UTCidentified

   Wir testen immer noch den Fix und die Ergebnisse sind immer noch gut. Wir stehen kurz vor dem Abschluss. Das nächste Update wird innerhalb einer Stunde sein.

8. 14. Juli 2026 um 11:39 UTCidentified

   Der Fix ist fertig und wir arbeiten an dem Bereitstellungsansatz mit minimalen Auswirkungen für die Kunden. Es wird systematisch an alle Kunden ausgerollt. Wir werden in der nächsten Stunde ein Update über den Einsatz bereitstellen.

9. 14. Juli 2026 um 12:51 UTCidentified

   Wir haben den Fix für einige ausgewählte Kunden bereitgestellt und die Ergebnisse weiter validiert. Der Massen-Rollout wird derzeit geplant. Wir werden Sie innerhalb der nächsten Stunde über den Fortschritt informieren.

10. 14. Juli 2026 um 14:24 UTCidentified

    Wir sind immer noch auf Kurs für die Patch-Bereitstellung und das Release wird jetzt einer zusätzlichen QA-Validierung unterzogen (für eine vollständige Produktionsbereitstellung erforderlich). Wir erwarten das nächste Update innerhalb einer Stunde.

11. 14. Juli 2026 um 16:11 UTCidentified

    Die QA und das Testen dauern etwas länger als erwartet, aber wir erwarten, dass der Einsatz innerhalb der nächsten Stunde beginnen wird. Wir werden Sie vor dem Start aktualisieren.

12. 14. Juli 2026 um 17:41 UTCmonitoring

    Der Einsatz des Hotfixes: Exalate Classic 5.35.4 - Jira Cloud, im Gange (https://community.exalate.com/t/jira-cloud-version-5-35-4/8215). Der Einsatz wird auf Anomalien genau überwacht. Wir werden Sie in einer Stunde aktualisieren.

13. 14. Juli 2026 um 18:55 UTCmonitoring

    Der Einsatz geht ununterbrochen weiter. Wir werden Sie zu gegebener Zeit aktualisieren, sobald es vollständig abgeschlossen ist.

14. 14. Juli 2026 um 22:14 UTCresolved

    Der Einsatz wurde erfolgreich abgeschlossen und das gemeldete Problem ist vollständig gelöst. Eine detaillierte RCA wird zu gegebener Zeit veröffentlicht.

15. 28. Juli 2026 um 20:00 UTCpostmortem

    **Impact:** Einige Classic Exalate für Jira Cloud-Verbindungen erlebten wiederholte, duplizierte Synchronisationen nach einer Infrastrukturmigration auf Atlassians Forge-Plattform. Auf betroffenen Verbindungen sahen Kunden: * **Doppelte Aktivität** – das gleiche Update, den gleichen Kommentar oder die gleiche Feldänderung, die immer wieder auf ein Problem angewendet wurde, als die Synchronisation durchgeführt wurde. * ** Wiedereröffnete / auferstandene Ausgaben** - Probleme, die geschlossen wurden, werden wiedereröffnet und andere Status- oder Feldwerte werden zwischen den gepaarten Ausgaben hin und her überschrieben. * **Verzerrte Dashboards und Berichte**, die durch das Volumen doppelter Änderungen gesteuert werden. * **Gebrochene Automatisierungen und Workflow-Validierungen** – weil sich der Name des Integrationsbenutzers (und die zugrunde liegende ID) geändert haben, haben sich die kundenseitigen Jira-Automatisierungsregeln und Workflow-Validatoren, die den "Exalate"-Benutzer mit Namen bezeichnet haben, nicht mehr wie konfiguriert verhalten. * **Stuck oder fehlgeschlagene Synchronisierungen**, und in einigen Fällen geht eine Verbindung aus, die manuelle Wiederholungen oder Wiederherstellungen erfordert. * Erhöhter **manueller Aufwand** für Teams, um Synchronisierungen zu entkleben und betroffene Probleme zu beheben. Nicht alle Kunden waren betroffen – die Auswirkungen waren von der Verbindungskonfiguration abhängig. Am meisten ausgesetzt waren lokale Verbindungen und Probleme, die zuvor unter der ursprünglichen "Exalate" -Identität erstellt oder aktualisiert wurden und dann unter der umbenannten berührt wurden. **Zusammenfassung:** Als Teil des Umzugs von Classic Exalate für Jira Cloud auf Atlassians Forge-Plattform wurde der Name für Exalate-Integrationsbenutzer in Jira geändert (von "Exalate" zu einer längeren Variante). Exalate hat diesen Namen verwendet, um seine eigenen Updates zu erkennen und eine Neusynchronisierung zu vermeiden. Sobald sich der Name geändert hatte, erkannte die App ihre eigenen Schreibvorgänge über betroffene Verbindungen nicht mehr und verarbeitete sie neu, als wären sie neue externe Änderungen - jeder Schreibvorgang löste eine andere Synchronisierung aus und erzeugte Schleifen. Die gleiche Identitätsänderung brach auch Kundenautomatisierungen und Validierungen, die den "Exalate" -Benutzer mit Namen bezeichneten. **Auflösung: Ein Patch \(5.35.4\), der die Updates von Exalate durch eine stabile Benutzerkennung anstelle des Anzeigenamens erkennt, wurde in den betroffenen Kundenumgebungen validiert und in der gesamten Jira Cloud-Flotte bereitgestellt. Die Synchronisation kehrte zum Normalzustand zurück, sobald die Bereitstellung abgeschlossen war. Atlassian hat seitdem den Namen des Integrationsbenutzers als "Exalate" wiederhergestellt und bestätigt, und er ist jetzt stabil - Reparatur-Automatisierungen, die sich auf den Namen beziehen. Wenn Schleifen doppelte oder wieder geöffnete Artikel erstellt haben, arbeiten wir mit betroffenen Kunden zusammen, um die betroffenen Probleme zu identifizieren und zu beheben. **Vorbeugende Maßnahmen:** Loop-Prävention hängt nicht mehr von einem veränderlichen Anzeigenamen ab; Wir fügen einen Impact-Review- und Benachrichtigungsschritt um plattformgesteuerte Änderungen und App-Updates sowie die automatisierte Erkennung von Synchronisationsschleifen und Datenbanksättigung hinzu, so dass die Wiederherstellung nicht von Kundenberichten abhängt. Wir entschuldigen uns für die Störung und bleiben der Zuverlässigkeit der Exalate-Plattform verpflichtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. Juni 2026 um 09:10 UTCinvestigating

   Wir untersuchen derzeit ein Problem, wenn wir versuchen, die Verbindung vom Exalat zu laden. Die App-Seite erhält einen Fehler. Die verbindung und die synchronisierungen sind nicht von dem ausfall betroffen, sie funktionieren immer noch, aber im moment ist es nicht möglich, die verbindung von der exalate zu sehen oder zu ändern. App-Seite. Wir werden innerhalb von 2 Stunden ein Update bereitstellen.

2. 23. Juni 2026 um 09:26 UTCmonitoring

   Das Problem ist gelöst. Exalate Dashboard ist nicht wieder online und stabil. Wir werden das System weiter überwachen.

3. 23. Juni 2026 um 12:47 UTCresolved

   Dieser Vorfall wurde behoben.

4. 7. Juli 2026 um 08:49 UTCpostmortem

   **Dauer:** 11:10 CEST - 11:26 CEST \(ca. 16 Minuten\). Volle Stabilität bestätigt um 14:47 Uhr MESZ. **Auswirkungen:** Die Exalate.app Verbindung und Dashboard-Seiten waren während dieses Fensters nicht zugänglich. Die Synchronisation des Problems war nicht betroffen - die Integrationen liefen weiterhin normal durch. Es gingen keine Daten verloren. **Zusammenfassung:** Am 23. Juni 2026 wurde die Exalate.app-Schnittstelle unzugänglich, nachdem eine interne Authentifizierungskomponente keine Verbindung zu ihrer Datenbank hergestellt hatte. Der Fehler wurde durch eine Berechtigungslücke verursacht, die während eines Produktionseinsatzes eingeführt wurde. **Zeitleiste:** * 11:10 Uhr CEST - Problem erkannt, Untersuchung eingeleitet * 11:26 CEST - Fix bereitgestellt, Service wiederhergestellt * 14:47 Uhr CEST - Volle Stabilität bestätigt **Wurzelursache:** Während eines Produktionseinsatzes am 19. Juni wurde ein Datenbanknachweis unabhängig in zwei Systemen konfiguriert. Bei einem späteren Konfigurationsupdate wurde eine subtile Fehlanpassung eingeführt. Die Diskrepanz blieb latent, weil die Anwendung bestehende Datenbankverbindungen aufrechterhielt. Ein routinemäßiges GKE-Wartungsereignis am 23. Juni recycelte die Anwendung und erzwang neue Verbindungen, die das Missverhältnis aufdeckten. **Beschluss:** Der Datenbanknachweis wurde angepasst und die Anwendung neu gestartet. Service kehrte zum vollen Betrieb ohne Datenverlust zurück. **Vorbeugende Maßnahmen:** * Überprüfungen der Authentifizierung nach der Bereitstellung wurden dem Bereitstellungs-Runbook hinzugefügt * Alarmierung für Verbindungsfehler in der Anwendungsdatenbank wurde implementiert * Der Credential-Konfigurationsprozess wird konsolidiert, um das Dual-System-Mismatch-Risiko zu beseitigen Wir entschuldigen uns für die Störung. Wir bleiben der Zuverlässigkeit der Exalate-Plattform verpflichtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 4. Mai 2026 um 13:24 UTCinvestigating

   Wir haben Berichte, dass einige Exlate-Cloud-Knoten nicht verfügbar sind. Unser Team untersucht derzeit das Problem.

2. 4. Mai 2026 um 13:42 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 4. Mai 2026 um 14:50 UTCidentified

   Unser Cloud-Team hat die Ursache identifiziert und ist aktiv daran beteiligt, sie zu beheben.

4. 4. Mai 2026 um 15:53 UTCidentified

   die betroffenen knoten erholen sich, während unser cloud-team weiter an dem problem arbeitet.

5. 4. Mai 2026 um 18:50 UTCmonitoring

   Alle Knoten sind in Betrieb, unser Cloud-Team überprüft weiterhin den betroffenen Cluster und arbeitet an seiner Wartung.

6. 4. Mai 2026 um 21:28 UTCresolved

   Das System wurde genau beobachtet und war stabil. Wir werden zu gegebener Zeit einen Post-Mortem-Vorfall vorlegen.

7. 25. Oktober 2026 um 10:27 UTCpostmortem

   **Vorfall:** Cloud Service Disruption exaltieren - 4. Mai 2026 **Dauer:** 10:45 – 22:10 CEST \(ca. 11 Stunden 25 Minuten, intermittierend\) **Auswirkungen:** Mehrere hundert Exalate Cloud-Knoten in einem unserer europäischen Cluster wurden während des Arbeitstages immer wieder unerreichbar. Synchronisationen auf betroffenen Knoten liefen während dieser Fenster nicht und wurden jedes Mal automatisch wieder aufgenommen, wenn der Dienst zurückgegeben wurde. Andere Cluster waren nicht betroffen. Es gingen keine Daten verloren und es war keine Kundenaktion erforderlich. **Zusammenfassung:** Am 4. Mai 2026 verlor die Datenbank, die diese Knoten bediente, ihre Standby-Replik, so dass eine Instanz den gesamten Datenverkehr übertrug. Sein Speicher teilte sich ein physisches Gerät mit einer anderen Arbeitslast, und unter Last schreibt die resultierende Behauptung verlangsamte Festplatte genug für unseren automatisierten Gesundheitscheck, um Zeit zu verlieren. Die Plattform behandelte das Timeout als Fehler und startete eine Datenbank neu, die beschäftigt war und nicht kaputt war, wodurch die Knoten in diesem Cluster jedes Mal getrennt wurden. **Zeitleiste:** * 10:45 CEST - Nodes als unerreichbar gemeldet, Untersuchung eingeleitet * 15:24 CEST — Vorfall erklärt und auf unserer Statusseite veröffentlicht 22:10 Uhr CEST — Standby-Replika wiederhergestellt, Cluster bestätigt gesund **Wurzelursache:** Speicherkonflikte auf einem freigegebenen physischen Gerät verursachten Health-Check-Timeouts, die automatisierte Neustarts auslösten. Der Neuaufbau des Standby-Replikats verstärkte die gleiche Behauptung, da das Streamen einer Kopie der Datenbank den Festplattendurchsatz von der Instanz entfernte, die noch Kunden bedient. **Beschluss:** Der Speicher wurde auf ein dediziertes Gerät verschoben, zusätzliche CPU zugewiesen und der Festplattendurchsatz auf der Primärseite erhöht, während er bewusst auf der Replika begrenzt wurde, so dass der Umbau Daten sanfter zog. **Vorbeugende Maßnahmen:** Wir trennen den Datenbankspeicher von anderen Workloads in dieser Umgebung, stimmen die Health-Check-Schwellenwerte neu ab, so dass eine Datenbank unter schwerer, aber gesunder Last nicht neu gestartet wird, parallelisieren den Node-Recovery-Pfad, um die Wiederherstellung zu verkürzen, und fügen Host-Level-Monitoring hinzu, um Konfliktwarnungen zu erhalten, bevor sie Kunden erreicht. Wir entschuldigen uns für die Störung. Wir bleiben der Zuverlässigkeit der Exalate-Plattform verpflichtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. April 2026 um 09:03 UTCinvestigating

   Wir untersuchen derzeit ein Problem, bei dem die Workspaces-Seite nicht geladen wird. Die Synchronisierung ist nicht betroffen, nur die Benutzeroberfläche von New Exalate wird nicht geladen.

2. 15. April 2026 um 09:04 UTCidentified

   Wir haben die Ursache des Problems identifiziert und arbeiten derzeit an einem Fix.

3. 15. April 2026 um 10:16 UTCmonitoring

   Die technischen Probleme wurden vollständig gelöst und die App ist jetzt in Betrieb. Wir verfolgen die Situation aufmerksam.

4. 15. April 2026 um 12:16 UTCresolved

   Die Anwendung lief reibungslos ohne Probleme und wir sehen keine Anomalien. Ein Post-Mortem wird zu gegebener Zeit zur Verfügung gestellt.

5. 7. Juli 2026 um 12:41 UTCpostmortem

   **Vorfall:** Exalate.app Arbeitsbereiche nicht laden - 15. April 2026 **Dauer:** 11:03 CEST – 12:16 CEST \(ca. 73 Minuten\). **Auswirkungen:** Die Benutzeroberfläche von Exalate.app war während dieses Fensters nicht zugänglich. Die Synchronisation des Problems war nicht betroffen. Es gingen keine Daten verloren. **Zusammenfassung:** Am 15. April 2026 wurde die Oberfläche von Exalate.app nach einem geplanten Update der Infrastrukturdaten nicht mehr zugänglich. Eine sekundäre Konfigurationsabhängigkeit wurde nicht als Teil der Änderung aktualisiert, was die Verbindung der Anwendung mit ihrer Datenbank verhinderte. **Zeitleiste:** * 11:03 Uhr CEST - Problem erkannt, Untersuchung eingeleitet * 11:04 CEST - Wurzelursache identifiziert * 12:16 CEST - Fix bereitgestellt, Service wiederhergestellt **Wurzelursache:** Eine Konfigurationsabhängigkeit, die während eines Credential-Updates verpasst wurde, ließ die Anwendung nicht in der Lage, sich bei ihrer Datenbank zu authentifizieren. Dies stand im Zusammenhang mit dem Vorfall vom 6. April; die zusätzliche Abhängigkeit wurde nun identifiziert und in das Rotationsverfahren einbezogen. **Beschluss:** Die betroffene Konfiguration wurde regeneriert und die Anwendung neu gestartet. Service kehrte zum vollen Betrieb ohne Datenverlust zurück. **Vorbeugende Maßnahmen:** * Alle Anmeldeinformationen wurden vollständig abgebildet und das Rotationsverfahren aktualisiert, um sie als eine einzige atomare Operation abzudecken Wir entschuldigen uns für die Störung. Wir bleiben der Zuverlässigkeit der Exalate-Plattform verpflichtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. April 2026 um 11:07 UTCinvestigating

   Wir untersuchen derzeit ein Problem, wenn die Arbeitsbereiche die Informationen nicht laden. Die Synchronisierung ist nicht betroffen, aber die Benutzeroberfläche von New Exalate wird nicht geladen.

2. 6. April 2026 um 11:28 UTCmonitoring

   Wir haben es identifiziert und eine Lösung wurde umgesetzt. Exalate.app ist derzeit in Betrieb und funktioniert wie erwartet, wir werden die Situation weiterhin überwachen und bald ein Update bereitstellen.

3. 6. April 2026 um 15:31 UTCresolved

   Dieser Vorfall wurde behoben.

4. 7. Juli 2026 um 12:30 UTCpostmortem

   **Vorfall:** Exalate.app Arbeitsbereiche nicht laden - 6. April 2026 **Dauer:** 13:07 CEST - 13:28 CEST \(ca. 21 Minuten\). **Auswirkungen:** Die Benutzeroberfläche von Exalate.app war während dieses Fensters nicht zugänglich. Die Synchronisation des Problems war nicht betroffen - die Integrationen liefen weiterhin normal durch. Es gingen keine Daten verloren. **Zusammenfassung:** Am 6. April 2026 wurde die Exalate.app-Schnittstelle unzugänglich, nachdem ein Infrastrukturnachweis im Rahmen eines geplanten Sicherheitsverbesserungsprogramms geändert wurde. Die Komponente, die für die Datenbankverbindung verantwortlich ist, speichert die Anmeldeinformationen beim Start zwischen und lädt sie nicht automatisch neu. Der vorherige Berechtigungsnachweis wurde entfernt, bevor die Komponente neu gestartet wurde, um den neuen aufzunehmen, was zu Authentifizierungsfehlern führte. **Zeitleiste:** * 13:07 CEST - Problem erkannt, Untersuchung eingeleitet * 13:28 CEST - Fix bereitgestellt, Service wiederhergestellt **Wurzelursache:** Eine Credential-Rotation wurde außer Kontrolle gebracht - das alte Credential wurde entfernt, bevor die Verbraucherkomponente mit dem neuen neu gestartet wurde. **Beschluss:** Die betroffenen Komponenten wurden mit den richtigen Anmeldeinformationen neu gestartet. Service kehrte zum vollen Betrieb ohne Datenverlust zurück. **Vorbeugende Maßnahmen:** * Es wurde ein Credential-Rotation-Verfahren eingerichtet, das eine obligatorische Sequenz durchsetzt: Aktualisieren, Neustarten von Verbrauchern, Verifizieren und Entfernen alter Anmeldeinformationen * Direkte Überwachung von Datenbankverbindungs-Authentifizierungsfehlern wird implementiert * Die Migration zu einem automatisierten Berechtigungsmanagement, das die manuelle Rotation für diesen Workload eliminiert, ist im Gange Wir entschuldigen uns für die Störung. Wir bleiben der Zuverlässigkeit der Exalate-Plattform verpflichtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. April 2026 um 15:41 UTCinvestigating

   Wir untersuchen, dass einige Exalate-Knoten nicht verfügbar sind. Wir werden in Kürze ein Update über die Untersuchung bereitstellen. Nächstes Update innerhalb von 2 Stunden - oder sobald wir relevante Updates haben

2. 2. April 2026 um 16:37 UTCidentified

   Das Problem wurde identifiziert und wir arbeiten derzeit daran, die Knoten so schnell wie möglich wiederherzustellen. Nächstes Update innerhalb von 2 Stunden oder sobald uns relevante Updates vorliegen

3. 2. April 2026 um 18:25 UTCidentified

   Wir setzen die Restaurierungsbemühungen fort. Einige Nodes sind bereits verfügbar. Das nächste Update erfolgt innerhalb von 2 Stunden oder sobald uns ein relevantes Update vorliegt.

4. 2. April 2026 um 19:18 UTCmonitoring

   Alle Nodes wurden erfolgreich wiederhergestellt. Unser Team überwacht das System genau, um eine anhaltende Stabilität zu gewährleisten.

5. 2. April 2026 um 21:26 UTCresolved

   Dieser Vorfall wurde behoben.

6. 25. Oktober 2026 um 10:25 UTCpostmortem

   **Vorfall:** Cloud-Service-Störung erhöhen - 2. April 2026 **Dauer:** 16:30 – 21:25 CEST \(4 Stunden 55 Minuten\) **Auswirkungen:** Etwa 60 Exalate Cloud-Knoten, die in unserem belgischen Cluster gehostet wurden, waren nicht verfügbar. Synchronisationen an diesen Knoten liefen während der Dauer des Ausfalls nicht und wurden automatisch wieder aufgenommen, sobald die Knoten wiederhergestellt wurden. Es gingen keine Daten verloren. **Zusammenfassung:** Während einer geplanten Rotation interner Kubernetes-Zertifikate hat jeder Worker-Knoten im Cluster gleichzeitig seinen Agenten neu gestartet. Jeder Worker bat dann gleichzeitig die Speicher-API, ihre Festplatten erneut zu überprüfen, und das Volumen der gleichzeitigen Anforderungen überforderte diese API. Da die Speicher-API nicht reagierte, konnten betroffene Knoten ihre Festplatten nicht anhängen und blieben offline. **Beschluss:** Der Traffic zur Storage API wurde isoliert und die Komponente neu gestartet, um den Backlog zu löschen. Knoten wurden dann in einer kontrollierten Reihenfolge wieder in Betrieb genommen, ein Arbeiter nach dem anderen, bis alle Knoten um 21:25 Uhr MESZ online waren. **Vorbeugende Maßnahmen:** Die Zertifikat-Rotationsprozedur wird so geändert, dass Knoten-Neustarts getaktet und gestapelt werden, anstatt gleichzeitig ausgeführt zu werden, und dieses Pacing wird in das Tooling eingebaut und nicht manuell angewendet. Darüber hinaus arbeiten wir mit unserem Infrastrukturpartner an einer Begrenzung der Schutzrate für die Speicher-API, an einer Änderung des Speichertreibers, damit Knoten ihre Festplatten lokal verifizieren, anstatt die API aufzurufen, und an einer Überwachung, die die API-Sättigung warnt, bevor sie Kunden betrifft. Wir entschuldigen uns für die Störung. Wir bleiben der Zuverlässigkeit der Exalate-Plattform verpflichtet.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. März 2026 um 15:13 UTCinvestigating

   We are investigating reports by some users that the Exalate app is not available right now.

2. 16. März 2026 um 15:56 UTCidentified

   We have identified the problem and the team is working to rectify this. We will provide an update of progress shortly.

3. 16. März 2026 um 16:09 UTCmonitoring

   The services are fully functional again. We are very closely monitoring the situation.

4. 16. März 2026 um 17:13 UTCresolved

   All systems are functional. We will be providing a post-mortem of the incident here in due course.

5. 31. März 2026 um 09:44 UTCpostmortem

   **Incident:** Exalate Application Unavailability — March 16, 2026 **Duration:** 16:13 CET – 17:09 CET \(approximately 56 minutes\) **Impact:** The Exalate UI was inaccessible during this window. Issue synchronisation was not affected — integrations continued to run normally throughout. No data was lost. **Summary:** On March 16, 2026, the Exalate application became unavailable following a production infrastructure configuration change. A resource allocation adjustment applied to a critical authentication component proved insufficient under production load, causing repeated service interruptions. **Timeline:** * 16:13 CET — Issue reported, investigation initiated * 16:56 CET — Root cause identified, remediation initiated * 17:09 CET — Fix deployed, service restored * 18:13 CET — Full stability confirmed **Root Cause:** A resource limit adjustment deployed without cross-team review under-provisioned a critical authentication component. Under production load, the platform repeatedly terminated the component, rendering the application inaccessible. **Resolution:** Resource limits were corrected, restoring service. A further optimisation was applied during a subsequent scheduled maintenance window following joint engineering review. **Preventive Measures:** * All production infrastructure configuration changes now require joint sign-off from infrastructure and engineering leads before deployment * Resource and capacity parameters validated against production load baselines prior to deployment

1. 13. März 2026 um 11:56 UTCinvestigating

   We are currently investigating an issue causing the Exalate website to be temporarily unavailable. Our team is actively working to identify the root cause and restore access as quickly as possible. This issue is strictly isolated to the Exalate.com webpage. Please note that Exalate.app and individual Nodes are not affected, and there is no impact on active integrations. We will provide an update within 4 hours, or sooner if new information becomes available.

2. 13. März 2026 um 13:03 UTCinvestigating

   Update: We are continuing to investigate the performance issues affecting Exalate.com. We have identified an ongoing incident with our hosting provider, Hostinger, and are currently verifying the extent of the impact on our services. You can track their status directly here: https://statuspage.hostinger.com We will provide another update as soon as we have more information, or within the next 4 hours.

3. 13. März 2026 um 14:31 UTCmonitoring

   We have identified and mitigated the issue that was causing performance degradation and intermittent unavailability of the Exalate.com website. After implementing mitigation measures, the website is now fully accessible and performing as expected. We have confirmed that Exalate.app, individual Nodes, and all active integrations remained unaffected throughout this incident. Our team will continue to monitor the situation closely to ensure continued stability. We will provide further updates only if the situation changes.

4. 13. März 2026 um 18:19 UTCresolved

   This incident has been resolved.

5. 31. März 2026 um 09:46 UTCpostmortem

   **Date:** March 17, 2026 **Duration:** 12:10 CET - 15:00 CET \(2 hours, 50 minutes\) **Impact:** The [exalate.com](http://exalate.com) website was completely inaccessible to all users for the duration of the incident. **Summary:** The hosting environment experienced resource exhaustion triggered by a sudden surge in web traffic. This was further exacerbated by a malfunctioning security plugin. **Timeline:** 12:10 CET: Incident start \(resource exhaustion begins\) 12:28 CET: Issue detected 14:40 CET: Root cause identified 15:00 CET: Service fully restored **Root Cause:** A spike in unique visitors has led to resource depletion on the hosting server. During the investigation, it was discovered that an installed security plugin was behaving inefficiently under high load, significantly compounding the CPU and memory usage, preventing the server from recovering. **Resolution:** Identified and blocked specific IP addresses responsible for an anomalous volume of requests. Deactivated and removed the problematic security plugin. Implemented an alternative solution to handle the plugin's core functionality without the performance overhead. **Preventive Measures:** Investigate and implement automated rate-limiting and IP blocking solutions \(e.g., WAF rules\) to handle traffic spikes.

1. 9. März 2026 um 06:59 UTCinvestigating

   We have reports of some Exlate cloud nodes being unavailable. Our team is currently investigating the issue.

2. 9. März 2026 um 07:11 UTCidentified

   Our cloud team has identified the root cause and is actively engaged in rectifying it.

3. 9. März 2026 um 07:20 UTCmonitoring

   The issue has been fully rectified and all nodes are fully restored. We are closely monitoring the situation.

4. 9. März 2026 um 09:00 UTCresolved

   After close monitoring, we consider the issue fully resolved. An RCA would be published here in due course.

5. 1. April 2026 um 03:39 UTCpostmortem

   **Incident:** Exalate Cloud Service Disruption - March 9, 2026 **Duration:** 07:30 CET – 08:10 CET \(approximately 40 minutes\) **Impact:** Some Exalate Cloud nodes experienced temporary service disruption. Database write operations were briefly affected. Issue synchronisation resumed automatically once the issue was resolved. No data was lost. **Summary:** On March 9, 2026, the primary database instance serving part of the Exalate Cloud infrastructure reached full storage capacity. This prevented the database from processing write operations, temporarily impacting node availability. **Timeline:** * 07:30 CET - Issue detected, investigation initiated * 08:05 CET - Storage expanded, database operations resumed * 08:10 CET - Fix verified, nodes confirmed operational * 10:00 CET - Full stability confirmed after extended monitoring **Root Cause:** The primary database storage volume gradually reached full capacity under normal operational growth. Proactive storage monitoring did not fire in time. **Resolution:** Database storage was expanded and the service returned to full operation automatically. Additional alerting configured.

1. 23. Januar 2026 um 09:59 UTCinvestigating

   We have identify an incident with exalate.app that is currently not loading. We are currently investigating the issue and will be providing updates within the hour. This is not affecting the sync of issues but the UI for exalate is currently unavailable.

2. 23. Januar 2026 um 10:18 UTCmonitoring

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

3. 23. Januar 2026 um 12:18 UTCresolved

   This incident has been resolved.

4. 31. März 2026 um 09:43 UTCpostmortem

   **Incident:** Exalate Application Unavailability — January 23, 2026 **Duration:** 10:59 CET – 11:18 CET \(approximately 19 minutes\) **Impact:** The Exalate UI was inaccessible during this window. Issue synchronisation was not affected — integrations continued to run normally throughout. No data was lost. **Summary:** On January 23, 2026, our monitoring detected a service outage affecting the Exalate application. The root cause was a deployment configuration change that unintentionally removed an active compute resource from the production environment. **Timeline:** * 10:59 CET — Issue detected, investigation initiated * 11:18 CET — Fix deployed, service restored * 13:18 CET — Full stability confirmed **Root Cause:** A deployment configuration change targeted the wrong resource section, resulting in an active production compute resource being removed and the application becoming inaccessible. **Resolution:** The affected resource was recreated and all services returned to full operation with no data loss. **Preventive Measures:** * Infrastructure-as-code changes must be validated in a non-production environment before production deployment * Peer review steps introduced to verify configuration targets prior to execution

1. 12. Dezember 2025 um 16:15 UTCinvestigating

   There is an outage on one of the clusters in Exalate cloud that might affect access to the nodes temporarily. We are currently investigating the issue to ensure that service is restored as soon as possible. A new update will be provided within 1 hour

2. 12. Dezember 2025 um 16:31 UTCidentified

   We have root caused the issue and the restoration process is underway already. The next update will be provided in 30mins.

3. 12. Dezember 2025 um 16:58 UTCidentified

   The recovery process is still ongoing. We will provide an update within an hour.

4. 12. Dezember 2025 um 19:11 UTCidentified

   We continue to work on the restoration of the affected nodes. We will be providing a new update in one hour.

5. 12. Dezember 2025 um 20:20 UTCidentified

   Nodes are being restored now, most nodes are now online, a full operational message will be posted once all nodes are back online.

6. 13. Dezember 2025 um 01:51 UTCidentified

   Most nodes are back on operational status, a full operational message will be posted once all nodes are back.

7. 13. Dezember 2025 um 02:56 UTCmonitoring

   All nodes are back to operational status now. We continue to monitor the stability closely.

8. 13. Dezember 2025 um 04:26 UTCresolved

   All Exalate nodes are stable and working normally. A post-mortem for the incident will be published in due course.

9. 22. Dezember 2025 um 04:43 UTCpostmortem

   **Incident: Service Outage - December 12, 2025** **Duration:** 16:35 CET - 03:01 CET \(approximately 10 hours\) **Impact:** A significant number of Exalate Cloud nodes experienced service unavailability, resulting in temporary disruption to data synchronization services. No data was lost during this incident. **Summary:** On December 12, 2025, our infrastructure monitoring detected a service outage affecting Exalate Cloud customers on our production clusters. The root cause was identified as a storage system failure triggered by network latency on a legacy infrastructure component, which caused storage connectivity issues for customer workloads. **Timeline:** * 16:35 CET - Issue detected by monitoring systems * 17:31 CET - Root cause identified, restoration initiated * 21:20 CET - Majority of nodes restored to service * 03:01 CET - Full service restoration confirmed **Root Cause:** A storage management component became unresponsive due to elevated network latency caused by a legacy networking layer. This resulted in storage disconnection for customer workloads. **Resolution:** The storage system was restored, all affected workloads were rescheduled, and the external dependency was updated to a supported version. All nodes were returned to full operation with no data loss. **Preventive Measures:** * Deploying patches to address the storage component stability issue * Accelerating migration away from the legacy networking layer to modern infrastructure * Implementing internal mirroring of critical external dependencies to eliminate reliance on third-party availability * Enhancing operational safeguards for infrastructure management procedures We sincerely apologize for the disruption this incident caused. Our team remains committed to improving the reliability and resilience of the Exalate Cloud platform.

1. 27. November 2025 um 11:47 UTCinvestigating

   We are investigating reports of some Exalate nodes being unavailable. We will be providing an update shortly on the investigation.

2. 27. November 2025 um 12:33 UTCidentified

   We have identified the problem and are working to restore full service as soon as possible.

3. 27. November 2025 um 13:47 UTCidentified

   Most nodes are currently running but we are still experiencing intermittent service failures. The full fix is being implemented now.

4. 27. November 2025 um 15:31 UTCmonitoring

   All nodes are back online and we are closely monitoring the cluster health.

5. 27. November 2025 um 16:51 UTCidentified

   We have detected some instability again and are investigating why some nodes are not reachable again.

6. 27. November 2025 um 20:48 UTCidentified

   All nodes are now back online and our team is working on stabilizing the services

7. 27. November 2025 um 22:04 UTCmonitoring

   All nodes are now fully operational. Any communication error reported in the console should now disappear after hitting "Resolve and retry". If you encounter any further problem please reach out to our support team. We continue to monitor the cluster closely and investigate to root cause the incident.

8. 28. November 2025 um 07:08 UTCresolved

   We have closely monitored the health of the affected Exalate nodes, and they are all performing as per expectation. A post-mortem of the incident will be published in due course.

9. 12. Dezember 2025 um 12:02 UTCpostmortem

   **Incident: Service Degradation - November 27, 2025** **Duration:** 11:26 CET - 21:37 CET \(~10 hours\) **Impact:** Approximately 700 Exalate Cloud nodes experienced intermittent connectivity issues, resulting in temporary disruption to data synchronization services. No data was lost during this incident. **Summary:** On November 27, 2025, our infrastructure monitoring detected service degradation affecting a subset of Exalate Cloud customers. The root cause was identified as storage I/O contention on the underlying database infrastructure, which caused the primary database to become unresponsive intermittently. **Timeline:** * 11:26 CET - Issue detected by monitoring systems * 11:30 CET - Engineering team began investigation * 15:30 CET - Initial mitigation applied \(infrastructure scaling\) * 18:30 CET - Root cause identified and permanent remediation initiated * 21:37 CET - Full service restoration confirmed **Root Cause:** Database storage was experiencing resource contention due to shared infrastructure components, causing elevated I/O latency. This triggered automated health checks to restart the database service repeatedly, compounding the connectivity issues. **Resolution:** The database was migrated to dedicated storage resources and allocated additional compute capacity. All affected nodes were restored to full operation with no data loss. **Preventive Measures:** * Implementing enhanced storage latency monitoring and alerting * Reviewing infrastructure health check configurations for database workloads * Auditing storage allocation across all database clusters to prevent similar contention We apologize for any inconvenience this incident may have caused. Our team remains committed to maintaining the reliability and performance of the Exalate Cloud platform.

1. 20. November 2025 um 09:43 UTCidentified

   We have identified an issue when trying to access the SyncRoom page, caused by a significant increase in DNS traffic originating from an external problem between Hostinger and Cloudflare. This external issue is currently impacting our service and is preventing the SyncRoom page and the community from loading Important Note: This issue does not affect the core Exalate functionality. Synchronization is continuing to work as expected. We are actively working to resolve this and will provide an update within the next two hours. Thank you for your patience.

2. 20. November 2025 um 10:29 UTCmonitoring

   A fix has been implemented by Hostinger and the services have been restored (Exalate community and SyncRoom) We will continue to monitor the results.

3. 20. November 2025 um 11:23 UTCresolved

   This incident has been resolved.

4. 1. April 2026 um 04:08 UTCpostmortem

   timeout

1. 4. Oktober 2025 um 06:18 UTCinvestigating

   We are investigating reports of users unable to access the Exalate console on some systems. We will be providing an update soon.

2. 4. Oktober 2025 um 06:30 UTCmonitoring

   The problem has been identified and the fix has been put in place.

3. 4. Oktober 2025 um 06:54 UTCresolved

   The issue is fully resolved and all nodes are operational. A post-mortem will be provided here in due course.

4. 14. November 2025 um 12:23 UTCpostmortem

   ## **Summary** On October 4, 2025, Exalate Cloud experienced an issue that caused some Exalate nodes to become temporarily inaccessible at 04:00 CEST. This resulted in UI access issues and potential synchronization interruptions for part of our customer base. All services were fully restored by 09:00 CEST. ## **Impact** Customers using Exalate cloud nodes experienced: * Inability to access nodes * Sync failures or delays * Temporary disruption of workflow automations No data loss occurred. ## **Root Cause** There was an error in the certification renewal process. This prevented affected nodes from completing required secure connections, making them temporarily unreachable. ## **Resolution** After identifying the cause, the certificate was renewed and deployed. Services began recovering immediately and full functionality was validated shortly thereafter. ## **Preventive Measures** We are implementing several improvements to prevent recurrence, including: * Expanded automated monitoring for certificate validity * Additional service health checks, including customer-facing endpoints * Automated renewal processes for critical certificates * Strengthened operational procedures around certificate lifecycle management

1. 3. Oktober 2025 um 09:43 UTCmonitoring

   We've released a configuration update for Jira Cloud connections running version 5.28.5. Who is affected: Customers using external script repositories in their Jira Cloud connections may experience script-related errors after upgrading to 5.28.5. Resolution: If you're experiencing issues with your scripts, please contact our support team at [email protected] - we'll assist you with a quick configuration update. Status: We're actively monitoring and reaching out to affected customers.

2. 5. November 2025 um 14:17 UTCresolved

   This incident has been resolved.

3. 1. April 2026 um 04:09 UTCpostmortem

   timeout

1. 24. September 2025 um 10:56 UTCinvestigating

   There is an outage on one of the clusters in Exalate cloud that might affect access to the nodes temporarily. We are currently investigating the issue to ensure that service is restored as soon as possible.

2. 24. September 2025 um 11:18 UTCidentified

   We have root caused the issue and the restoration process is underway already. The next update will be provided in 30mins.

3. 24. September 2025 um 11:47 UTCidentified

   The recovery process is still ongoing. We will provide an update within an hour.

4. 24. September 2025 um 13:00 UTCmonitoring

   All nodes are fully recovered. We continue to closely monitor the situation.

5. 24. September 2025 um 14:50 UTCidentified

   Our monitoring uncovered a problem still lingering with the cluster. We are working to restore full functionality as soon as possible.

6. 24. September 2025 um 16:56 UTCidentified

   Node recovery has presented some challenges and is taking longer than expected. We continue to strive to bring all nodes back online as soon as possible. Next update will be provided within 2 hours.

7. 24. September 2025 um 18:47 UTCidentified

   Infrastructure component failures have been addressed by our Engineering team. Next step: We are restarting the individual Exalate nodes impacted by the failure. More information will be provided in an hour.

8. 24. September 2025 um 19:54 UTCidentified

   We continue restarting the individual Exalate nodes impacted by the failure. 5% of the affected nodes have been brought back online. Further updates to be expected in an hour

9. 24. September 2025 um 20:51 UTCidentified

   The team is actively working through the restart sequence for all individual Exalate nodes. This is a deliberate, multi-step process to ensure stability upon full restoration. Further updates to be expected in an hour.

10. 24. September 2025 um 21:45 UTCidentified

    Following the deliberate, multi-step sequence, the engineering team has now moved into the main restoration phase. We are actively scaling up the restart of the affected Exalate nodes. We'll continue to monitor stability closely. We will provide the next update in one hour.

11. 24. September 2025 um 22:49 UTCidentified

    The engineering team continue working on the main restoration phase. We'll continue to monitor stability closely. Further updates to be expected in an hour

12. 24. September 2025 um 23:50 UTCidentified

    During the scale-up phase, the restoration process has presented some challenges that are taking longer than initially expected to resolve. The engineering team is actively working to address these stability issues. We will provide the next update within one hour.

13. 25. September 2025 um 00:48 UTCidentified

    The previous technical challenges have been addressed. We have re-initiated the scale-up of the Exalate nodes and are closely monitoring the environment for stability. We will provide the next update within one hour.

14. 25. September 2025 um 01:44 UTCidentified

    We are continuing the scale-up of the Exalate nodes. The team is maintaining a close monitoring posture to ensure stability throughout this process. We will provide the next update in one hour.

15. 25. September 2025 um 03:23 UTCmonitoring

    All nodes are fully restored and functioning normally now. We continue to monitor the cluster carefully to ensure stability.

16. 25. September 2025 um 14:21 UTCresolved

    We have extensively monitored the cluster health and there have been no outstanding issues found.

17. 10. Oktober 2025 um 10:41 UTCpostmortem

    ## Executive Summary On September 24, 2025, Exalate experienced a service interruption lasting 17 hours and 28 minutes that affected our cloud-hosted integration nodes. During this time, customers were unable to synchronize data between their integrated systems. **No customer data was lost.** We sincerely apologize for the inconvenience and want to share what happened and how we're preventing future issues. ## What Happened **Timeline:** * **10:02 UTC \(Sept 24\):** Infrastructure issue detected through customer reports * **13:00 UTC:** Partial service restoration achieved * **13:45 UTC:** Secondary technical issue caused complete service unavailability * **17:24 UTC:** Core infrastructure restored * **21:00 UTC:** Priority customer services online * **03:30 UTC \(Sept 25\):** Full service restoration completed **Root Cause:** A network connectivity issue on our hosting platform triggered a cascading infrastructure failure. The recovery process was complex due to database resilience challenges and infrastructure management system complications. ## Customer Impact **During the outage:** * Data synchronization between systems \(Jira, ServiceNow, etc.\) was unavailable * Automated workflow processes were temporarily halted **What was NOT affected:** * **No customer data was lost or corrupted** * All existing synchronized data remained intact * Customer configurations and sync histories were preserved ## Our Response We immediately activated our 24/7 incident response team, maintained continuous status page updates, directly contacted Enterprise customers, and coordinated with infrastructure providers throughout the recovery. ## Prevention Measures We're implementing comprehensive improvements on an accelerated timeline: **Immediate \(October 2025\):** * Enhanced infrastructure monitoring and alerting systems * Comprehensive disaster recovery documentation **Short-term \(November 2025\):** * Infrastructure resilience improvements * Automated recovery procedures * Regular disaster recovery testing **Medium-term \(Q1 2026\):** * Multi-cloud architecture implementation * Advanced predictive monitoring ## Customer Support If you need assistance related to this outage: * **Enterprise Customers:** Use your dedicated support channels * **Standard Support:** Submit tickets through our support portal * **Status Updates:** Monitor our status page for ongoing information We apologize for this service disruption and appreciate your patience. Your trust is essential to our business, and we're committed to earning it through reliable service delivery and continuous improvement.

1. 29. August 2025 um 16:18 UTCinvestigating

   We are investigating a problem where IssueLinks are being removed from Jira cloud tickets. Progress and actions will be notified accordingly, if you encountered this problem please reach us on support portal.

2. 29. August 2025 um 16:57 UTCidentified

   The issue has been identified and we are performing remediation actions.

3. 29. August 2025 um 21:04 UTCidentified

   All nodes have been moved from the affected version and a workaround to remediate the possible effects on issue links is being investigated.

4. 31. August 2025 um 19:00 UTCmonitoring

   We identified the affected instances and provided remediation steps to all affected clients to restore the removed links.

5. 5. September 2025 um 11:56 UTCresolved

   The issue affecting Jira Cloud issue links has been fully resolved. A detailed postmortem will be published soon outlining the root cause and preventive measures being implemented.

6. 18. September 2025 um 06:57 UTCpostmortem

   # Exalate v5.28 Issue Links Synchronization - Technical Incident Report **Incident Date:** 29/Aug/2025 **Duration:** ~4 hours from detection to rollback completion **Impact:** Issue link synchronization behavior change affecting multiple customer instances **Status:** Resolved with data restoration completed ## Timeline The incident was first detected  on 29/Aug at 17:56 when a customer reported issue links being removed after upgrading to v5.28. Within eight minutes, at 18:04, the support team received multiple similar reports and immediately requested a rollback. The formal incident response was initiated at 18:17, and the rollback process to v5.27.0 began at 18:48. The rollback was completed across all affected instances by 22:12 the same day, approximately four hours after initial detection. Recovery efforts continued over the weekend. On 30/Aug at 09:43, the data restoration team was assembled and began developing recovery procedures. The comprehensive customer communication deployment occurred on 01/Sep at 17:05, providing affected customers with restoration instructions and individualized support. _\(All times CET\)_ ‌ ‌ ## Root Cause Analysis The technical issue stemmed from a synchronization enhancement in v5.28 that compared issue links between source and destination systems. The implementation operated under the assumption that links present on the destination but not on the source represented synchronization inconsistencies requiring removal. This approach failed to distinguish between links managed by Exalate and links created independently outside the synchronization scope. Several contributing factors enabled this issue to reach production. The scope definition did not account for mixed environments where synchronized and non-synchronized links coexist on the same system. Test coverage focused primarily on standard synchronization flows rather than these mixed data environments. Additionally, the modification affected a broader scope than initially anticipated during the development and review process. The impact characteristics were significant but recoverable. Multiple customer instances experienced removal of issue links that existed outside the intended synchronization scope. However, service functionality continued throughout the incident, and comprehensive audit logs preserved all affected link data, which enabled complete restoration of the removed links.Regarding data security and privacy, the audit logs contain only metadata elements such as issue identifiers, link types, and relationship mappings. No sensitive customer content, comments, or detailed issue information was captured in these logs. This metadata-only approach ensured that the restoration process could proceed while maintaining appropriate data protection standards. ## Learnings On the positive side, the incident response team made a rapid rollback decision, quickly identifying this as the appropriate technical solution rather than attempting a forward fix. The comprehensive logging infrastructure proved invaluable, enabling complete data restoration from audit trails. Cross-functional coordination worked well across engineering, customer success, and operations teams. The structured communication approach maintained clarity and transparency throughout the resolution process. The incident also revealed important areas for system enhancement. Synchronization logic in complex integration scenarios requires better handling of mixed data environments where multiple systems manage different subsets of the same data types. Testing scope needs expansion to cover mixed synchronized and non-synchronized environments comprehensively. Change evaluation processes require enhancement for modifications that affect customer data. Monitoring capabilities need improvement to enable proactive detection of synchronization behavior changes before customer impact. Several process improvements have been \(or are being\) implemented as a result. Enhanced code review procedures now include additional requirements specifically for data modification operations. Expanded testing protocols cover scenarios involving mixed data environments and include dedicated data preservation validation. Improved monitoring systems detect synchronization pattern changes and unusual data modification activities. Updated release procedures include enhanced evaluation criteria for data-affecting changes and improved rollback automation capabilities.