OpenText incident
Frankfurt EU18 experienced service unavailability
OpenText experienced a critical incident on July 20, 2026 affecting Frankfurt EU18, lasting 49m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating Jul 20, 2026, 01:34 PM UTC
Frankfurt EU18 farm is experiencing service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking Number: IM3964099
- monitoring Jul 20, 2026, 01:55 PM UTC
Frankfurt EU18 farm was experiencing service unavailability. Service has been restored and is now being validated. We appreciate your patience. Tracking Number: IM3964099
- resolved Jul 20, 2026, 02:23 PM UTC
Frankfurt EU18 farm experienced service unavailability. The issue is now resolved. We appreciate your patience. Tracking Number: IM3964099
- postmortem Jul 23, 2026, 03:12 PM UTC
**Overview** On July 20, 2026, Incident Management was engaged to investigate two separate incidents resulting in degraded performance and functionality impacts for multiple OpenText™ Enterprise Service Management clients hosted on the Frankfurt EU18 farm. The tracking numbers for the incidents are below: Incident 1: **IM3963996** – 09:42 to 10:45 GMT Incident 2: **IM3964099** – 12:59 to 13:40 GMT **Impact** Customers experienced intermittent service degradation, resulting in delayed workflows, reduced application performance, and temporary loss of functionality. **Root Cause** The root cause analysis identified two primary contributing factors: * **RabbitMQ Metadata Store Instability**: An instability within the RabbitMQ Metadata store caused inconsistencies in queue metadata, resulting in messaging disruptions across the platform. * **Connection Recovery Failures**: Certain application services were unable to automatically re-establish stable RabbitMQ connections after failures, leading to degraded platform performance and functionality. **Resolution** Service was restored by restarting the RabbitMQ cluster and the dependent application services to re-establish healthy messaging connectivity across the platform. As a corrective measure, an emergency change was performed during off-business hours to rebuild the RabbitMQ cluster and perform a rolling restart of all dependent platform deployments. **Action Plan** Engineering teams continue to investigate the underlying root cause of this incident and identify additional corrective and preventive measures to reduce the risk of recurrence. As part of the remediation effort, a long-term stability improvement program has been launched to enhance RabbitMQ resilience, strengthen application connection recovery mechanisms, and expand proactive monitoring and alerting capabilities. These improvements, along with enhancements planned for Release 26.3.1, are expected to further improve system stability and significantly reduce the likelihood of similar incidents in the future.