Exalate outage history

Atlassian is experiencing an issue with Jira and other systems currently - details here: https://status.atlassian.com/ This may affect your Exalate connections if you are connecting to a Jira instance.

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

Atlassian have put a fix in place to resolve the issue. Your synchronization should already be back to normal, but please reach out to support in case of any issues.

All Atlassian systems are back to normal, and the synchronization is working as expected. In case of any issues with your sync, please create a support ticket and we will be happy to assist.

N/A

Following up on an unadverted change in the application name which causes the proxy user to be shown with the full name of the application instead of just "Exalate". This is already notified to Atlassian and we are awaiting the required action on their end to revert the change. Impact: Updates made by Exalate will display "Exalate Classic Connector for Jira (Two-way Sync)" as the user making the change.

We continue to investigate the best approach to solve this issue with the help of Atlassian support.

We are actively working with Atlassian support to determine the best resolution for this issue as soon as possible.

We are actively working with Atlassian support to determine the best resolution for this issue as soon as possible. We will be providing the next update within 6 hours or as soon as we have any relevant information.

The proxy user name was reverted back to Exalate. We are considering the incident as resolved.

Some Jira Cloud nodes are experiencing instability over the past 30mins. The problem is limited and only affects some customers. We will be providing an update shortly.

We will be actioning a change on Exalate Cloud to improve stability. The impact on your node will be that limited to a restart with the node being unavailable for a couple of min. The inconvenience is regretted.

The rolling restart of the nodes is in progress. You will experience a brief restart on JCloud nodes. We will keep you posted with our progress.

The restart is still in progress and is going without any issues. We will update you as soon as it is completed.

All nodes are back to normal operation. We continue to monitor the situation closely.

After close monitoring, the issue is considered as fully resolved. We will be posting a RCA here in due course.

**Incident:** JiraCloud Nodes Experiencing Instability - July 16, 2026 **Duration:** 12:28 CET – 16:57 CET \(approximately 4.5 hours\). Full stability confirmed at 18:18 CET. **Impact:** Some Jira Cloud integration nodes experienced intermittent instability during this window. Typically ~10 nodes were affected simultaneously. Issue synchronisation on unaffected nodes continued to run normally. No data was lost. **Summary:** On July 16, 2026, some Jira Cloud integration nodes on the Exalate Cloud platform experienced intermittent restarts and timeouts. The root cause was a resource constraint on one of the underlying hosting servers. A coincidental software update initially directed investigation towards the application layer, but cross-environment analysis confirmed that nodes on other infrastructure were unaffected — narrowing the issue to a single hosting server. **Timeline:** * 12:28 CET - Issue detected, investigation initiated * 13:03 CET - Stabilisation measures applied, rolling restart initiated * 16:57 CET - All nodes back to normal operation * 18:18 CET - Full stability confirmed **Root Cause:** A hosting server reached its resource ceiling due to concentrated workload during a routine software update cycle. This caused intermittent resource starvation for nodes running on that server. **Resolution:** Workload was redistributed across the hosting infrastructure to balance resource utilisation. All affected nodes recovered with no data loss. **Preventive Measures:** * Proactive alerting thresholds for infrastructure resource utilisation have been implemented * Workload distribution across hosting servers has been rebalanced to prevent concentration We apologize for the disruption. We remain committed to the reliability of the Exalate platform.

We've received multiple reports of syncs looping after update to the new Jira Cloud forge app. Our initial investigation leads us to believe this is happening due to the change in the Proxy User account. We are actively working on determining the root cause and applying a fix.

We continue to investigate this issue with our engineers to determine the root cause.

The root cause has been identified and we are working on a fix. Please expect another update within an hour.

The fix is currently being validated to find the best approach forward. We will provide another update within the hour.

Unfortunately, the testing of the fix revealed an unexpected issue and we are now fine tuning the fix in order ensure that it incorporates all possible use cases. We will have an update for you in an hour.

The new fix has been created and initial tests are promising. We are deep in QA with the new fix and will provide an update within the hour about the results. The inconvenience is regretted.

We are still testing the fix and results are still good. We are close to finalizing it. Next update will be within the hour.

The fix is ready and we are working on the deployment approach with minimal impact for customers. It will be systematically rolled out to all clients. We will provide an update in the next hour about the deployment.

We have deployed the fix to a few select customers and validated results further. The mass rollout is being planned right now. We will update you within the next hour about progress.

We are still on course for the patch deployment and the release is going through additional QA validation now (required for a full production deployment). We expect to have the next update within an hour.

The QA and testing is taking slightly longer than expected, but we expect to start the deployment within the next hour. We will update you before starting this.

The deployment of the hotfix: Exalate Classic 5.35.4 - Jira Cloud, in underway (https://community.exalate.com/t/jira-cloud-version-5-35-4/8215). The deployment is being closely monitored for any anomalies. We will update you in an hour.

The deployment continues uninterrupted. We will update you in due course as soon as it is fully completed.

The deployment was completed successfully and the issue reported stands fully resolved. A detailed RCA will be published in due course.

**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: * **Duplicate activity** — the same update, comment, or field change applied to an issue over and over as the sync looped. * **Reopened / resurrected issues** — issues that had been closed being reopened, and other status or field values being overwritten back and forth between the paired issues. * **Distorted dashboards and reports** driven by the volume of duplicate changes. * **Broken automations and workflow validations** — 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. * **Stuck or failed syncs**, and in some cases a connection going down, requiring manual retries or recovery. * Increased **manual effort** for teams to unstick syncs and correct affected issues. Not all customers were affected — 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. **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 — each write triggering another sync, producing loops. The same identity change also broke customer automations and validations that referenced the "Exalate" user by name. **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 — 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. **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. We apologise for the disruption and remain committed to the reliability of the Exalate platform.

We are currently investigating an issue when trying to load the connection from the exalate.app page gets an error. The connection and syncs are not affected by the outage, they are still working, but at the moment is not possible to see or modify connection from the exalate.app page. We will be providing an update within 2 hours.

The issue has been resolved. Exalate Dashboard is not back online and stable. We will continue monitoring the system.

This incident has been resolved.

**Duration:** 11:10 CEST - 11:26 CEST \(approximately 16 minutes\). Full stability confirmed at 14:47 CEST. **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. **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. **Timeline:** * 11:10 CEST - Issue detected, investigation initiated * 11:26 CEST - Fix deployed, service restored * 14:47 CEST - Full stability confirmed **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. **Resolution:** The database credential was aligned and the application was restarted. Service returned to full operation with no data loss. **Preventive Measures:** * Post-deployment authentication verification checks have been added to the deployment runbook * Alerting for application database connectivity failures has been implemented * The credential configuration process is being consolidated to eliminate the dual-system mismatch risk We apologize for the disruption. We remain committed to the reliability of the Exalate platform.

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

We are continuing to investigate this issue.

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

affected nodes are recovering while our cloud team continues to work on the issue.

All nodes are operational, our cloud team continues to review the affected cluster and work on its maintenance.

The system has been under close observation and it has been stable. We will provide a post-mortem to the incident in due course.

**Incident:** Exalate Cloud service disruption - 4 May 2026 **Duration:** 10:45 – 22:10 CEST \(approximately 11 hours 25 minutes, intermittent\) **Impact:** Several hundred Exalate Cloud nodes on one of our European clusters became repeatedly unreachable during the working day. Synchronisations on affected nodes did not run during these windows and resumed automatically each time service returned. Other clusters were unaffected. No data was lost, and no customer action was required. **Summary:** On 4 May 2026, the database serving these nodes lost its standby replica, leaving one instance carrying all traffic. Its storage shared a physical device with another workload, and under load the resulting contention slowed disk writes enough for our automated health check to time out. The platform treated the timeout as a failure and restarted a database that was busy rather than broken, disconnecting the nodes on that cluster each time. **Timeline:** * 10:45 CEST — Nodes reported unreachable, investigation initiated * 15:24 CEST — Incident declared and published to our status page * 22:10 CEST — Standby replica restored, cluster confirmed healthy **Root Cause:** Storage contention on a shared physical device caused health-check timeouts that triggered automated restarts. Rebuilding the standby replica amplified the same contention, as streaming a copy of the database drew disk throughput away from the instance still serving customers. **Resolution:** Storage was moved to a dedicated device, additional CPU allocated, and disk throughput raised on the primary while deliberately limited on the replica so the rebuild drew data more gently. **Preventive measures:** We are separating database storage from other workloads across this environment, retuning health-check thresholds so a database under heavy but healthy load is not restarted, parallelising the node recovery path to shorten restoration, and adding host-level monitoring so contention alerts before it reaches customers. We apologise for the disruption. We remain committed to the reliability of the Exalate platform.

We are currently investigating an issue where the workspaces page is not loading. The sync is not affected, only the UI of New Exalate is not loading.

We have identified the root cause of the issue and are currently working on a fix.

The technical issues have been fully resolved and the app is up and running now. We are closely monitoring the situation.

The application has been running smoothly without any issues and we do not see any anomalies. A post-mortem will be provided in due course.

**Incident:** Exalate.app Not Loading Workspaces - April 15, 2026 **Duration:** 11:03 CEST – 12:16 CEST \(approximately 73 minutes\). **Impact:** The Exalate.app UI was inaccessible during this window. Issue synchronisation was not affected. No data was lost. **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. **Timeline:** * 11:03 CEST - Issue detected, investigation initiated * 11:04 CEST - Root cause identified * 12:16 CEST - Fix deployed, service restored **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. **Resolution:** The affected configuration was regenerated and the application was restarted. Service returned to full operation with no data loss. **Preventive Measures:** * All credential dependencies have been fully mapped and the rotation procedure updated to cover them as a single atomic operation We apologize for the disruption. We remain committed to the reliability of the Exalate platform.

We are currently investigating an issue when the workspaces are not loading the information. The sync is not affected, but the UI from New Exalate is not loading.

We have identified and an solution was implemented. Exalate.app is currently operational and working as expected, we will continue monitoring the situation and will provide an update soon.

This incident has been resolved.

**Incident:** Exalate.app Not Loading Workspaces - April 6, 2026 **Duration:** 13:07 CEST - 13:28 CEST \(approximately 21 minutes\). **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. **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. **Timeline:** * 13:07 CEST - Issue detected, investigation initiated * 13:28 CEST - Fix deployed, service restored **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. **Resolution:** The affected components were restarted with the correct credentials. Service returned to full operation with no data loss. **Preventive Measures:** * A credential rotation procedure has been established enforcing a mandatory sequence: update, restart consumers, verify, then remove old credentials * Direct monitoring for database connectivity authentication failures is being implemented * Migration to automated credential management that eliminates manual rotation for this workload is underway We apologize for the disruption. We remain committed to the reliability of the Exalate platform.

We are investigating some Exalate nodes being unavailable. We will be providing an update shortly on the investigation. Next update within 2 hours - or as soon as we have any relevant updates

The issue was identified and we are currently working on restoring the nodes as soon as possible. Next update within 2 hours or as soon as we have any relevant updates

We continue with the restoration efforts. Some nodes are already available. Next update will be within 2 hours or as soon as we have any relevant update.

All nodes have been successfully restored. Our team is closely monitoring the system to ensure continued stability.

This incident has been resolved.

**Incident:** Exalate Cloud service disruption - 2 April 2026 **Duration:** 16:30 – 21:25 CEST \(4 hours 55 minutes\) **Impact:** Approximately 60 Exalate Cloud nodes hosted on our Belgian cluster were unavailable. Synchronisations on those nodes did not run for the duration of the outage and resumed automatically once the nodes were restored. No data was lost. **Summary:** During a scheduled rotation of internal Kubernetes certificates, every worker node in the cluster restarted its agent at the same time. Each worker then simultaneously asked the storage API to re-verify its disks, and the volume of simultaneous requests overwhelmed that API. With the storage API unresponsive, affected nodes could not attach their disks and remained offline. **Resolution:** Traffic to the storage API was isolated and the component restarted to clear the backlog. Nodes were then returned to service in a controlled sequence, one worker at a time, until all nodes were online at 21:25 CEST. **Preventive measures:** The certificate rotation procedure is being changed so that node restarts are paced and batched rather than executed simultaneously, and this pacing is being built into the tooling rather than applied manually. In addition, we are working with our infrastructure partner on protective rate limiting for the storage API, on a change to the storage driver so that nodes verify their disks locally instead of calling the API, and on monitoring that alerts on API saturation before it affects customers. We apologise for the disruption. We remain committed to the reliability of the Exalate platform.

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

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

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

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

**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

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.

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.

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.

This incident has been resolved.

**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.

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

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

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

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

**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.

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.

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

This incident has been resolved.

**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

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

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

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

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

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

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

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

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

**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.

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

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

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

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

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

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

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.

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.

**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.

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.

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

This incident has been resolved.

timeout

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

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

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

## **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

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.

This incident has been resolved.

timeout

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.

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

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

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

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

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.

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.

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

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.

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.

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

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.

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.

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.

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

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

## 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.

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.

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

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

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

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.

# 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.