Cloudera Status

On March 10, 2026, between 15:23 UTC to 17:09 UTC, users may have experienced intermittent connectivity issues accessing the workloads in the Cloudera Management Console of the US region. This disruption was traced to the termination of jumpgate-proxy pods, which entered an OOMKilled status after memory utilization exceeded configured limits. This, in turn, impacted connectivity between the control plane and the workloads within the Cloudera Management Console. Service consistency was restored by increasing the memory limits and replica counts for the jumpgate-proxy deployment. To prevent recurrence, we will implement alerting mechanisms for jumpgate pod memory utilization and pod states \(such as CrashLoopBackoff or OOMKilled events\). This will enable us to proactively detect and mitigate memory pressure before it impacts service availability. We will implement autoscaling to autoheal and respond to increased load. We sincerely apologise for any inconvenience this service disruption may have caused. We appreciate your patience as we worked to restore service functionality.

On March 10, 2026, around 19:56 UTC users may have started experiencing intermittent timeouts accessing the Cloudera Management Console across the US, EU, and AP regions.  This disruption was traced to an internal service certificate expiration where, despite a successful renewal initiation, a misalignment in the deployment sequence prevented the updated credentials from propagating to the active service mesh. The impact was strictly limited to administrative console and API access; all existing data workloads and running environments continued to operate without interruption.  Service consistency was restored by regenerating and manually applying the certificates across all affected clusters. To prevent recurrence, we have audited all regional clusters and are transitioning to an automated lifecycle for mesh-level certificates.  We sincerely apologize for any inconvenience this service disruption may have caused. We are addressing monitoring gaps to detect these issues before they impact you, our customers. We appreciate your patience as we worked to restore service functionality.

The intermittent performance and access issues with the Cloudera Management Console and FreeIPA were triggered by a scheduled service upgrade intended to improve platform stability. Our investigation determined that a change in a core component introduced a latent configuration issue. This specific condition was not exposed in our testing environments, preventing dependent services from applying dynamic configuration updates in production and leading to the outage. We've taken immediate action to prevent this issue from recurring: System Fix: The problematic component change was rolled back, and a permanent patch was deployed to restore proper dynamic configuration functionality. Process Overhaul: We've implemented a more rigorous upgrade process with mandatory, near-production scale validation steps that specifically test for these types of configuration failures. Enhanced Monitoring: We significantly improved our monitoring and alerting capabilities to detect these abnormal service behaviours much earlier, ensuring a faster response time. We are dedicated to providing a reliable platform and will continue to invest in our infrastructure and processes. Thank you again for your patience and understanding

The intermittent performance and access issues with the Cloudera Management Console and FreeIPA were triggered by a scheduled service upgrade intended to improve platform stability. Our investigation determined that a change in a core component introduced a latent configuration issue. This specific condition was not exposed in our testing environments, preventing dependent services from applying dynamic configuration updates in production and leading to the outage. We've taken immediate action to prevent this issue from recurring: System Fix: The problematic component change was rolled back, and a permanent patch was deployed to restore proper dynamic configuration functionality. Process Overhaul: We've implemented a more rigorous upgrade process with mandatory, near-production scale validation steps that specifically test for these types of configuration failures. Enhanced Monitoring: We significantly improved our monitoring and alerting capabilities to detect these abnormal service behaviours much earlier, ensuring a faster response time. We are dedicated to providing a reliable platform and will continue to invest in our infrastructure and processes. Thank you again for your patience and understanding

A recent system update, intended to enhance stability of our platform, inadvertently led to an unforeseen memory issue affecting a critical internal service responsible for platform access management. ‌ A subsequent incoming request spike caused the memory limits exhaustion, which resulted in the service to become intermittently unavailable. ‌ The memory allocation for the service was manually increased, which restored normal operations. This change was then made permanent to circumvent any recurrence. ‌ We have implemented more robust monitoring and alerting to detect similar issues in the future before they can impact our customers. This includes updating the existing alerts for resource exhaustion and adding new alerts based on the incident, to ensure that the right teams are notified immediately. ‌ We are dedicated to providing a reliable and performant platform. We will continue to invest in improving our infrastructure and processes to prevent future disruptions. We appreciate your patience and understanding as we worked to resolve this issue.

On 23rd of June, we were notified that our Consumption Dashboards were not displaying current usage data from June 19th, 2024. Upon further investigation, we identified that the pipeline that ingests data into consumption was not progressing due to out-of-memory crash errors. The issue was caught and fixed, but the catch-up of the pipeline caused a delay of 2-3 days. While the reprocessing was happening in the background, customers could still use [https://my.cloudera.com/account/usage](https://my.cloudera.com/account/usage) to get the same consumption reports. Our teams have instituted preemptive measures and refined our internal protocols to manage similar incidents proactively in the future. We apologize for any inconvenience this may have caused and remain committed to implementing all necessary measures to prevent the recurrence of such issues.

On June 3rd 2025 our internal systems detected intermittent 504 errors on the Data Catalog service UI. ‌ The interruption was caused by Data Catalog service components prematurely indicating they were ready to handle requests immediately after a scheduled system restart. In reality, these components were still performing essential internal data updates, a process which took approximately 24 minutes. During this period, the service was unable to fully process user requests, leading to intermittent access issues and 504 errors. ‌ To prevent similar occurrences, we have enhanced our system's readiness checks to ensure the Data Catalog service is fully prepared to serve traffic. ‌ We apologize for any inconvenience caused by the service disruption. We are committed to providing a reliable and robust platform and truly appreciate your understanding.

On 3rd April 2025, there was an intermittent service disruption impacting login and CLI operations via the Management Console portal. Subsequent investigation identified the root cause stemmed from an increase in latency with internal DNS servers. In response, corrective measures were promptly taken to address the issue. Furthermore, we have implemented supplementary checks and preemptive actions to prevent similar occurrences in the future. We apologise for any inconvenience caused by the service disruption. We are fully committed to providing a reliable and robust platform and truly appreciate your understanding.

On March 12, 2025, intermittent service disruptions were experienced due to an expired certificate served by an endpoint. Despite an automated successful certificate renewal, staggered pod restarts resulted in inconsistencies, with older ingress controller pods serving the expired certificate alongside a recently updated pod. This discrepancy led to intermittent user errors. Resolution was achieved through a systematic restart of all affected components, ensuring uniform application of the renewed certificate and restoring service consistency. We have also implemented measures to prevent similar occurrences. We sincerely apologize for any inconvenience this service disruption may have caused. We are committed to maintaining the highest standards of service reliability and appreciate your understanding.

On March 03, 2025, a service disruption occurred within our EU Control plane. This disruption resulted from a configuration change implemented during a routine production cluster upgrade, which inadvertently triggered a synchronization error, leading to service unavailability. ‌ Upon detection of the issue, our engineering teams promptly allocated additional resources to the affected cluster. This action facilitated the restoration of services to an operational state. The root cause of the disruption was the result of an oversight during the standard upgrade procedure, which resulted in the synchronization failure. ‌ We sincerely apologize for any inconvenience this service disruption may have caused. We have implemented corrective measures and refined our upgrade protocols to mitigate the risk of similar incidents in the future. We are committed to maintaining the highest standards of service reliability and appreciate your understanding.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The maintenance activity on the EU control plane has completed ahead of time. Service is now fully operational. Thank you for your patience and understanding.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

Completed with no interruption of the service in question.

The scheduled maintenance has been completed in all regions.