Frankfurt EU8 experienced intermittent service unavailability.

Update timeline

1. investigating Jul 27, 2026, 09:03 AM UTC

   Frankfurt EU8 is currently experiencing intermittent service unavailability. Teams are currently assembled and working to resolve the issue. We appreciate your patience. Tracking Number: IM3968415

2. monitoring Jul 27, 2026, 09:48 AM UTC

   Frankfurt EU8 experienced intermittent service unavailability. Service has been restored and is now being validated. We appreciate your patience. Tracking Number: IM3968415

3. monitoring Jul 27, 2026, 10:54 AM UTC

   Frankfurt EU8 experienced intermittent service unavailability. Service has been restored and is now being validated. We appreciate your patience. Tracking Number: IM3968415

4. resolved Jul 27, 2026, 11:42 AM UTC

   Frankfurt EU8 experienced intermittent service unavailability. The issue is now resolved. We appreciate your patience. Tracking Number: IM3968415

5. postmortem Jul 29, 2026, 02:26 PM UTC

   **Interim Root Cause** **Tracking number:** IM3968415 PM1011655 **Incident windows:** July 27, 2026, from 06:31 GMT to 09:41 GMT **Services affected:** OpenText™ Enterprise Service Management \(ESM EU8\) **Overview** On July 27, 2026, at 07:10 GMT, Incident Management was engaged to investigate intermittent access issues and service unavailability. **Impact** Several clients experienced intermittent access issues and service unavailability across the ESM EU8 environment. **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** The CPU allocation was increased, and the RabbitMQ queues were rebalanced to improve system stability and performance. Systematic restarts of the platform pods were completed at 07:56 GMT, which restored the core services. However, the SLT service continued to experience issues. The cluster was rebuilt, and services normalized at 09:41 GMT. Additional manual checks were completed across the environment to clear false degradation alerts, and no further issues were observed. Validations were completed at 11:38 GMT, ending the impact. **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. OpenText took the following actions and will determine additional preventative actions as needed. ‌ • Implemented static pod assignment for RabbitMQ, replacing dynamic allocation to reduce the risk of pod contention. - **COMPLETE** • Increased CPU resources allocated to RabbitMQ pods to alleviate performance bottlenecks and improve overall system stability. - **COMPLETE**