{
"vendor": "Exalate",
"slug": "exalate",
"platform": "statuspage",
"status_url": "https://status.exalate.com",
"last_checked": "2026-09-16T12:28:20Z",
"last_state": "ok",
"history_backfilled": true,
"first_watched": "2026-09-04T07:06:16Z",
"incidents": [
{
"body": "N/A",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-27T07:27:28.917+02:00",
"resolved_inferred": false,
"started_at": "2026-08-27T06:36:21.945+02:00",
"state": "postmortem",
"title": "Atlassian has an active incident that might be affecting your connections",
"updated_at": "2026-09-08T07:41:57.202+02:00",
"url": "https://stspg.io/1zv4bdk0zng4"
},
{
"body": "The proxy user name was reverted back to Exalate. \n\nWe are considering the incident as resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-24T18:33:41.433+02:00",
"resolved_inferred": false,
"started_at": "2026-07-24T08:12:42.939+02:00",
"state": "resolved",
"title": "App name change/proxy user on Atlassian Jira Cloud",
"updated_at": "2026-07-24T18:33:41.455+02:00",
"url": "https://stspg.io/n5ww3rtwm8xc"
},
{
"body": "After close monitoring, the issue is considered as fully resolved. We will be posting a RCA here in due course.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-16T19:18:22.171+02:00",
"resolved_inferred": false,
"started_at": "2026-07-16T13:28:02.375+02:00",
"state": "resolved",
"title": "JiraCloud nodes experiencing some instablility",
"updated_at": "2026-07-16T19:18:22.201+02:00",
"url": "https://stspg.io/4yjwxcgp2stm"
},
{
"body": "**Impact:** Some Classic Exalate for Jira Cloud connections experienced repeated, duplicated synchronisations following an infrastructure migration to Atlassian's Forge platform. On affected connections customers saw:\n\n* **Duplicate activity** \u2014 the same update, comment, or field change applied to an issue over and over as the sync looped.\n* **Reopened / resurrected issues** \u2014 issues that had been closed being reopened, and other status or field values being overwritten back and forth between the paired issues.\n* **Distorted dashboards and reports** driven by the volume of duplicate changes.\n* **Broken automations and workflow validations** \u2014 because the integration user's name \\(and underlying ID\\) changed, customer-side Jira Automation rules and workflow validators that referenced the \"Exalate\" user by name stopped behaving as configured.\n* **Stuck or failed syncs**, and in some cases a connection going down, requiring manual retries or recovery.\n* Increased **manual effort** for teams to unstick syncs and correct affected issues.\n\nNot all customers were affected \u2014 impact depended on connection configuration. The most exposed were local connections and issues that had previously been created or updated under the original \"Exalate\" identity and were then touched under the renamed one.\n\n**Summary:** As part of moving Classic Exalate for Jira Cloud to Atlassian's Forge platform, the name shown for Exalate's integration user inside Jira changed \\(from \"Exalate\" to a longer variant\\). Exalate used that name to recognise its own updates and avoid re-synchronising them. Once the name changed, the app no longer recognised its own writes on affected connections and re-processed them as if they were new external changes \u2014 each write triggering another sync, producing loops. The same identity change also broke customer automations and validations that referenced the \"Exalate\" user by name.\n\n**Resolution:** A patch \\(5.35.4\\) that recognises Exalate's own updates by a stable user identifier rather than the display name was validated on affected customer environments and deployed across the Jira Cloud fleet. Synchronisation returned to normal once deployment completed. Atlassian has since restored and confirmed the integration user's name as \"Exalate\", and it is now stable \u2014 repairing automations that reference it by name. Where loops created duplicate or reopened items, we are working with affected customers to identify and correct the affected issues.\n\n**Preventive measures:** Loop-prevention no longer depends on a changeable display name; we are adding an impact-review and notification step around platform-driven changes and app updates, and automated detection of synchronisation loops and database saturation so recovery does not depend on customer reports.\n\nWe apologise for the disruption and remain committed to the reliability of the Exalate platform.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "critical",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-15T00:14:53.867+02:00",
"resolved_inferred": false,
"started_at": "2026-07-14T00:15:07.444+02:00",
"state": "postmortem",
"title": "Exalate looping synchronizations in Jira Cloud forge app",
"updated_at": "2026-07-28T22:00:52.708+02:00",
"url": "https://stspg.io/s3crnhc22dvh"
},
{
"body": "**Duration:** 11:10 CEST - 11:26 CEST \\(approximately 16 minutes\\). Full stability confirmed at 14:47 CEST.\n\n**Impact:** The Exalate.app connection and dashboard pages were inaccessible during this window. Issue synchronisation was not affected - integrations continued to run normally throughout. No data was lost.\n\n**Summary:** On June 23, 2026, the Exalate.app interface became inaccessible after an internal authentication component failed to connect to its database. The failure was caused by a credential mismatch introduced during a production deployment.\n\n**Timeline:**\n\n* 11:10 CEST - Issue detected, investigation initiated\n* 11:26 CEST - Fix deployed, service restored\n* 14:47 CEST - Full stability confirmed\n\n**Root Cause:** During a production deployment on June 19, a database credential was configured independently in two systems. A subtle mismatch was introduced during a subsequent configuration update. The mismatch remained latent because the application maintained existing database connections. A routine GKE maintenance event on June 23 recycled the application, forcing new connections that exposed the mismatch.\n\n**Resolution:** The database credential was aligned and the application was restarted. Service returned to full operation with no data loss.\n\n**Preventive Measures:**\n\n* Post-deployment authentication verification checks have been added to the deployment runbook\n* Alerting for application database connectivity failures has been implemented\n* The credential configuration process is being consolidated to eliminate the dual-system mismatch risk\n\nWe apologize for the disruption. We remain committed to the reliability of the Exalate platform.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-23T14:47:15.232+02:00",
"resolved_inferred": false,
"started_at": "2026-06-23T11:10:12.633+02:00",
"state": "postmortem",
"title": "Exalate.app is not loading the connections.",
"updated_at": "2026-07-07T10:50:17.708+02:00",
"url": "https://stspg.io/9yfh79nlw3x8"
},
{
"body": "The system has been under close observation and it has been stable. We will provide a post-mortem to the incident in due course.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-04T23:28:00.549+02:00",
"resolved_inferred": false,
"started_at": "2026-05-04T15:24:36.446+02:00",
"state": "resolved",
"title": "Some exalate cloud nodes unavailable",
"updated_at": "2026-05-04T23:28:00.563+02:00",
"url": "https://stspg.io/gx8h235d2wh5"
},
{
"body": "**Incident:** Exalate.app Not Loading Workspaces - April 15, 2026\n\n**Duration:** 11:03 CEST \u2013 12:16 CEST \\(approximately 73 minutes\\).\n\n**Impact:** The Exalate.app UI was inaccessible during this window. Issue synchronisation was not affected. No data was lost.\n\n**Summary:** On April 15, 2026, the Exalate.app interface became inaccessible following a planned infrastructure credential update. A secondary configuration dependency was not updated as part of the change, preventing the application from connecting to its database.\n\n**Timeline:**\n\n* 11:03 CEST - Issue detected, investigation initiated\n* 11:04 CEST - Root cause identified\n* 12:16 CEST - Fix deployed, service restored\n\n**Root Cause:** A configuration dependency missed during a credential update left the application unable to authenticate to its database. This was related to the April 6 incident; the additional dependency has now been identified and incorporated into the rotation procedure.\n\n**Resolution:** The affected configuration was regenerated and the application was restarted. Service returned to full operation with no data loss.\n\n**Preventive Measures:**\n\n* All credential dependencies have been fully mapped and the rotation procedure updated to cover them as a single atomic operation\n\nWe apologize for the disruption. We remain committed to the reliability of the Exalate platform.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-15T14:16:47.556+02:00",
"resolved_inferred": false,
"started_at": "2026-04-15T11:03:44.256+02:00",
"state": "postmortem",
"title": "Exalate.app Not loading workspaces",
"updated_at": "2026-07-07T14:41:35.699+02:00",
"url": "https://stspg.io/8v3fcq24ffw3"
},
{
"body": "**Incident:** Exalate.app Not Loading Workspaces - April 6, 2026\n\n**Duration:** 13:07 CEST - 13:28 CEST \\(approximately 21 minutes\\).\n\n**Impact:** The Exalate.app UI was inaccessible during this window. Issue synchronisation was not affected - integrations continued to run normally throughout. No data was lost.\n\n**Summary:** On April 6, 2026, the Exalate.app interface became inaccessible after an infrastructure credential was rotated as part of a planned security improvement programme. The component responsible for database connectivity caches credentials at startup and does not reload them automatically. The previous credential was removed before the component had been restarted to pick up the new one, causing authentication failures.\n\n**Timeline:**\n\n* 13:07 CEST - Issue detected, investigation initiated\n* 13:28 CEST - Fix deployed, service restored\n\n**Root Cause:** A credential rotation completed out of sequence - the old credential was removed before the consuming component had been restarted with the new one.\n\n**Resolution:** The affected components were restarted with the correct credentials. Service returned to full operation with no data loss.\n\n**Preventive Measures:**\n\n* A credential rotation procedure has been established enforcing a mandatory sequence: update, restart consumers, verify, then remove old credentials\n* Direct monitoring for database connectivity authentication failures is being implemented\n* Migration to automated credential management that eliminates manual rotation for this workload is underway\n\nWe apologize for the disruption. We remain committed to the reliability of the Exalate platform.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-06T17:31:14.304+02:00",
"resolved_inferred": false,
"started_at": "2026-04-06T13:07:19.702+02:00",
"state": "postmortem",
"title": "Exalate.app Not loading workspaces",
"updated_at": "2026-07-07T14:30:44.792+02:00",
"url": "https://stspg.io/y2mn8vgygbyf"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-04-02T23:26:46.402+02:00",
"resolved_inferred": false,
"started_at": "2026-04-02T17:41:49.000+02:00",
"state": "resolved",
"title": "Some Exalate Nodes are currently unreachable",
"updated_at": "2026-04-02T23:26:46.418+02:00",
"url": "https://stspg.io/tkcfkcqs6vqf"
},
{
"body": "**Incident:** Exalate Application Unavailability \u2014 March 16, 2026\n\n**Duration:** 16:13 CET \u2013 17:09 CET \\(approximately 56 minutes\\)\n\n**Impact:** The Exalate UI was inaccessible during this window. Issue synchronisation was not affected \u2014 integrations continued to run normally throughout. No data was lost.\n\n**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.\n\n**Timeline:**\n\n* 16:13 CET \u2014 Issue reported, investigation initiated\n* 16:56 CET \u2014 Root cause identified, remediation initiated\n* 17:09 CET \u2014 Fix deployed, service restored\n* 18:13 CET \u2014 Full stability confirmed\n\n**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.\n\n**Resolution:** Resource limits were corrected, restoring service. A further optimisation was applied during a subsequent scheduled maintenance window following joint engineering review.\n\n**Preventive Measures:**\n\n* All production infrastructure configuration changes now require joint sign-off from infrastructure and engineering leads before deployment\n* Resource and capacity parameters validated against production load baselines prior to deployment",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-16T18:13:49.862+01:00",
"resolved_inferred": false,
"started_at": "2026-03-16T16:13:29.699+01:00",
"state": "postmortem",
"title": "Exalate App unavailable",
"updated_at": "2026-03-31T11:45:04.117+02:00",
"url": "https://stspg.io/jj8cdrrkx6pp"
},
{
"body": "**Date:** March 17, 2026  \n**Duration:** 12:10 CET - 15:00 CET \\(2 hours, 50 minutes\\)  \n**Impact:**   \nThe [exalate.com](http://exalate.com) website was completely inaccessible to all users for the duration of the incident.  \n**Summary:**  \nThe hosting environment experienced resource exhaustion triggered by a sudden surge in web traffic. This was further exacerbated by a malfunctioning security plugin.  \n**Timeline:**  \n12:10 CET: Incident start \\(resource exhaustion begins\\)  \n12:28 CET: Issue detected  \n14:40 CET: Root cause identified  \n15:00 CET: Service fully restored  \n**Root Cause:**  \nA 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.  \n**Resolution:**  \nIdentified and blocked specific IP addresses responsible for an anomalous volume of requests.  \nDeactivated and removed the problematic security plugin.  \nImplemented an alternative solution to handle the plugin's core functionality without the performance overhead.  \n**Preventive Measures:**  \nInvestigate and implement automated rate-limiting and IP blocking solutions \\(e.g., WAF rules\\) to handle traffic spikes.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-13T19:19:19.354+01:00",
"resolved_inferred": false,
"started_at": "2026-03-13T12:56:32.372+01:00",
"state": "postmortem",
"title": "Exalate Website Unavailable",
"updated_at": "2026-03-31T11:47:14.921+02:00",
"url": "https://stspg.io/nxd2555g5c0j"
},
{
"body": "**Incident:** Exalate Cloud Service Disruption - March 9, 2026\n\n**Duration:** 07:30 CET \u2013 08:10 CET \\(approximately 40 minutes\\)\n\n**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.\n\n**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.\n\n**Timeline:**\n\n* 07:30 CET - Issue detected, investigation initiated\n* 08:05 CET - Storage expanded, database operations resumed\n* 08:10 CET - Fix verified, nodes confirmed operational\n* 10:00 CET - Full stability confirmed after extended monitoring\n\n**Root Cause:** The primary database storage volume gradually reached full capacity under normal operational growth. Proactive storage monitoring did not fire in time. \n\n**Resolution:** Database storage was expanded and the service returned to full operation automatically. Additional alerting configured.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-09T10:00:15.499+01:00",
"resolved_inferred": false,
"started_at": "2026-03-09T07:59:15.724+01:00",
"state": "postmortem",
"title": "Some exalate cloud nodes unavailable",
"updated_at": "2026-04-01T05:40:58.827+02:00",
"url": "https://stspg.io/sx8zjzlywws7"
},
{
"body": "**Incident:** Exalate Application Unavailability \u2014 January 23, 2026\n\n**Duration:** 10:59 CET \u2013 11:18 CET \\(approximately 19 minutes\\)\n\n**Impact:** The Exalate UI was inaccessible during this window. Issue synchronisation was not affected \u2014 integrations continued to run normally throughout. No data was lost.\n\n**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.\n\n**Timeline:**\n\n* 10:59 CET \u2014 Issue detected, investigation initiated\n* 11:18 CET \u2014 Fix deployed, service restored\n* 13:18 CET \u2014 Full stability confirmed\n\n**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.\n\n**Resolution:** The affected resource was recreated and all services returned to full operation with no data loss.\n\n**Preventive Measures:**\n\n* Infrastructure-as-code changes must be validated in a non-production environment before production deployment\n* Peer review steps introduced to verify configuration targets prior to execution",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "critical",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-01-23T13:18:08.623+01:00",
"resolved_inferred": false,
"started_at": "2026-01-23T10:59:34.897+01:00",
"state": "postmortem",
"title": "Exalate.app page is not loading.",
"updated_at": "2026-03-31T11:43:25.284+02:00",
"url": "https://stspg.io/cd4b7kxn96b7"
},
{
"body": "**Incident: Service Outage - December 12, 2025**\n\n**Duration:** 16:35 CET - 03:01 CET \\(approximately 10 hours\\)\n\n**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.\n\n**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.\n\n**Timeline:**\n\n* 16:35 CET - Issue detected by monitoring systems\n* 17:31 CET - Root cause identified, restoration initiated\n* 21:20 CET - Majority of nodes restored to service\n* 03:01 CET - Full service restoration confirmed\n\n**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. \n\n**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.\n\n**Preventive Measures:**\n\n* Deploying patches to address the storage component stability issue\n* Accelerating migration away from the legacy networking layer to modern infrastructure\n* Implementing internal mirroring of critical external dependencies to eliminate reliance on third-party availability\n* Enhancing operational safeguards for infrastructure management procedures\n\nWe sincerely apologize for the disruption this incident caused. Our team remains committed to improving the reliability and resilience of the Exalate Cloud platform.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-12-13T05:26:23.891+01:00",
"resolved_inferred": false,
"started_at": "2025-12-12T17:15:42.392+01:00",
"state": "postmortem",
"title": "Exalate nodes unrachable",
"updated_at": "2025-12-22T05:45:14.781+01:00",
"url": "https://stspg.io/rd83ldyn1cpn"
},
{
"body": "**Incident: Service Degradation - November 27, 2025**\n\n**Duration:** 11:26 CET - 21:37 CET \\(~10 hours\\)\n\n**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.\n\n**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.\n\n**Timeline:**\n\n* 11:26 CET - Issue detected by monitoring systems\n* 11:30 CET - Engineering team began investigation\n* 15:30 CET - Initial mitigation applied \\(infrastructure scaling\\)\n* 18:30 CET - Root cause identified and permanent remediation initiated\n* 21:37 CET - Full service restoration confirmed\n\n**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.\n\n**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.\n\n**Preventive Measures:**\n\n* Implementing enhanced storage latency monitoring and alerting\n* Reviewing infrastructure health check configurations for database workloads\n* Auditing storage allocation across all database clusters to prevent similar contention\n\nWe apologize for any inconvenience this incident may have caused. Our team remains committed to maintaining the reliability and performance of the Exalate Cloud platform.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-28T08:08:51.590+01:00",
"resolved_inferred": false,
"started_at": "2025-11-27T12:47:06.787+01:00",
"state": "postmortem",
"title": "Some Exalate nodes are unavailable",
"updated_at": "2025-12-12T13:05:04.538+01:00",
"url": "https://stspg.io/l9115ny1wt16"
},
{
"body": "timeout",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-20T12:23:51.183+01:00",
"resolved_inferred": false,
"started_at": "2025-11-20T10:43:55.000+01:00",
"state": "postmortem",
"title": "SyncRoom website and Community not loading.",
"updated_at": "2026-04-01T06:08:58.008+02:00",
"url": "https://stspg.io/pxd0x42b2xzn"
},
{
"body": "## **Summary**\n\nOn 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.\n\n## **Impact**\n\nCustomers using Exalate cloud nodes experienced:\n\n* Inability to access nodes\n* Sync failures or delays\n* Temporary disruption of workflow automations\n\nNo data loss occurred.\n\n## **Root Cause**\n\nThere was an error in the certification renewal process. This prevented affected nodes from completing required secure connections, making them temporarily unreachable.\n\n## **Resolution**\n\nAfter identifying the cause, the certificate was renewed and deployed. Services began recovering immediately and full functionality was validated shortly thereafter.\n\n## **Preventive Measures**\n\nWe are implementing several improvements to prevent recurrence, including:\n\n* Expanded automated monitoring for certificate validity\n* Additional service health checks, including customer-facing endpoints\n* Automated renewal processes for critical certificates\n* Strengthened operational procedures around certificate lifecycle management",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-10-04T08:54:10.810+02:00",
"resolved_inferred": false,
"started_at": "2025-10-04T08:18:30.901+02:00",
"state": "postmortem",
"title": "Some Exalate nodes down (specially on Jira Cloud)",
"updated_at": "2025-11-14T13:26:16.943+01:00",
"url": "https://stspg.io/l79mwvmds746"
},
{
"body": "timeout",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-05T15:17:11.347+01:00",
"resolved_inferred": false,
"started_at": "2025-10-03T11:43:15.924+02:00",
"state": "postmortem",
"title": "Jira Cloud: Script Configuration Update Available",
"updated_at": "2026-04-01T06:10:05.984+02:00",
"url": "https://stspg.io/vh1fxn8cw8p1"
},
{
"body": "## Executive Summary\n\nOn 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.\n\n## What Happened\n\n**Timeline:**\n\n* **10:02 UTC \\(Sept 24\\):** Infrastructure issue detected through customer reports\n* **13:00 UTC:** Partial service restoration achieved\n* **13:45 UTC:** Secondary technical issue caused complete service unavailability\n* **17:24 UTC:** Core infrastructure restored\n* **21:00 UTC:** Priority customer services online\n* **03:30 UTC \\(Sept 25\\):** Full service restoration completed\n\n**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.\n\n## Customer Impact\n\n**During the outage:**\n\n* Data synchronization between systems \\(Jira, ServiceNow, etc.\\) was unavailable\n* Automated workflow processes were temporarily halted\n\n**What was NOT affected:**\n\n* **No customer data was lost or corrupted**\n* All existing synchronized data remained intact\n* Customer configurations and sync histories were preserved\n\n## Our Response\n\nWe 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.\n\n## Prevention Measures\n\nWe're implementing comprehensive improvements on an accelerated timeline:\n\n**Immediate \\(October 2025\\):**\n\n* Enhanced infrastructure monitoring and alerting systems\n* Comprehensive disaster recovery documentation\n\n**Short-term \\(November 2025\\):**\n\n* Infrastructure resilience improvements\n* Automated recovery procedures\n* Regular disaster recovery testing\n\n**Medium-term \\(Q1 2026\\):**\n\n* Multi-cloud architecture implementation\n* Advanced predictive monitoring\n\n## Customer Support\n\nIf you need assistance related to this outage:\n\n* **Enterprise Customers:** Use your dedicated support channels\n* **Standard Support:** Submit tickets through our support portal\n* **Status Updates:** Monitor our status page for ongoing information\n\nWe 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-09-25T16:21:59.869+02:00",
"resolved_inferred": false,
"started_at": "2025-09-24T12:56:38.160+02:00",
"state": "postmortem",
"title": "Some Exalate nodes unavailable",
"updated_at": "2025-10-10T12:42:45.808+02:00",
"url": "https://stspg.io/ttk3v3gd1nm6"
},
{
"body": "# Exalate v5.28 Issue Links Synchronization - Technical Incident Report\n\n**Incident Date:** 29/Aug/2025  \n**Duration:** ~4 hours from detection to rollback completion  \n**Impact:** Issue link synchronization behavior change affecting multiple customer instances  \n**Status:** Resolved with data restoration completed\n\n## Timeline\n\nThe incident was first detected\u00a0 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.\n\nRecovery 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.  \n_\\(All times CET\\)_\n\n\u200c\n\n\u200c\n\n## Root Cause Analysis\n\nThe 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.\n\nSeveral 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.\n\nThe 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.\n\n## Learnings\n\nOn 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.\n\nThe 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.\n\nSeveral 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-09-05T13:56:12.479+02:00",
"resolved_inferred": false,
"started_at": "2025-08-29T18:18:41.274+02:00",
"state": "postmortem",
"title": "Jira Cloud IssueLinks being Removed",
"updated_at": "2025-09-18T08:58:22.951+02:00",
"url": "https://stspg.io/fb3lck2qyn1y"
}
]
}