Anaplan Status Page

Aug 15, 2026 · resolved Aug 15

We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

Jul 24, 2026 · resolved Jul 31

**Summary**  On July 24, 2026, at 20:22 UTC, our engineering team began investigating an issue affecting customers in our ca1: Cloud — Canada region. Customers with affected workspaces were unable to open their models. As a precaution, while we validated the scope of the issue, we restricted access to the region behind a maintenance page at 02:18 UTC on July 25. General access to CA1 was restored at 17:24 UTC on July 25. Bring Your Own Key \(BYOK\) workspaces remained offline for additional safeguards, and were re-enabled progressively as those safeguards were validated. The incident was fully resolved on July 31, 2026, at 13:47 UTC.  **Root cause**  The disruption was caused by a defect in a third-party component used within our BYOK service. The defect only surfaced under a very specific combination of events occurring in a particular order on the same host. When a BYOK workspace was unloaded, the component failed tofully clear one of its local resources, leaving behind a stale reference. When a BYOK workspace was subsequently loaded onto the same host, the component attempted to clean up that stale reference before proceeding. During this step, it incorrectly executed a removal that extended beyond the stale reference and deleted files that were still in active use.   The affected files were captured in our regular backups. Once our engineering team identified the source of the activity, isolated it, and applied protective controls to stop any further impact, restoration became a controlled process of returning each affected file to its most recent backup.  **Recovery**  Our engineering team identified the issue and isolated it at its source, then worked systematically to restore the affected files. This allowed us to bring non-BYOK workspaces back online in a controlled sequence, and general access to CA1 was restored at 17:24 UTC on July 25.  We deliberately kept BYOK workspaces offline while our team worked with the third-party vendor to reproduce the trigger in a controlled, non-production environment. This reproduction gave us the diagnostic evidence the vendor needed to build a fix and to confirm the exact cause. It also allowed us to develop and validate our own temporary safeguards — targeted changes to how BYOK workspaces are scheduled — that eliminated the specific combination of conditions required to trigger the defect. These safeguards act as compensating controls to bring BYOK workspaces back online while the third party completes the permanent fix to the underlying component. We re-enabled BYOK workspaces once those safeguards were validated, ensuring the trigger conditions couldn't recur. The incident was fully resolved on July 31, 2026, at 13:47 UTC.  **Corrective and preventative actions**  Our corrective actions follow two complementary tracks. The first removes the specific combination of conditions required to trigger the defect, using controls we have developed and deployed ourselves as compensating safeguards. The second is the permanent fix to the underlying component itself, which the third party is delivering. Together, these tracks address both the trigger and the defect, so that neither can produce another incident of this kind. We are implementing the following actions to prevent recurrence:  * We have deployed changes that prevent the specific combination of conditions required to trigger the defect. This is a temporary but effective control that removes the trigger today, ahead of the permanent fix.  * We are working with the third party to deploy their validated fix. This removes the defect at its source and closes the underlying cause of this incident.  * We are strengthening how we validate BYOK third-party components in non-production before they reach production, including reproducing a wider range of workspace lifecycle scenarios and event sequences. This gives us stronger assurance to surface these types of issues in non-production and are addressed before they can affect customers.  * We have deployed dedicated alerting on the specific event pattern that triggered this incident and are actively reviewing additional file-level alerting. These alerts provide an additional safety net and earlier warning, enabling faster preventative action before customers are affected.  **Closing**  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.   If you have further questions or concerns, please visit our [Support](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F) website. We appreciate your patience during this incident and value the trust you place in Anaplan.

Jul 29, 2026 · resolved Jul 29

On July 29, 2026, between 10:57 UTC and 11:53 UTC, customers in our us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan regions experienced degraded performance. This resulted in delayed model and workspace access, slow page load times, and slower logins across the platform, as well as delayed execution of CloudWorks™ integrations. All other regions were unaffected during this time.  **Root Cause**  The incident was triggered by an automated security software update deployed across our platform servers. This simultaneous update caused an unexpected, short-lived spike in storage activity that temporarily exceeded the storage systems' processing capacity. The resulting latency disrupted communication between internal metadata services and core system servers, causing the service connection pools to become unresponsive and preventing them from automatically recovering.  **Recovery**  Our engineering team identified the issue and took immediate action. We performed rolling restarts of the affected metadata services to clear the unresponsive connection pools and stabilize the systems. By 11:30 UTC, affected systems had recovered. Following this, the CloudWorks™ scheduler was restarted to process and clear the backlog of integration tasks. The issue was fully resolved by 11:53 UTC.  **Corrective & Preventative Actions**  We are implementing the following actions to prevent recurrence:  * We are implementing enhanced storage performance tiers and traffic-prioritization controls to isolate key platform workloads from other background system activities.  * We are updating our internal service connection frameworks to automatically detect and gracefully recover from unexpected system connection interruptions.  * We are refining our security software deployment processes to stagger rollouts and limit simultaneous resource utilization.  * We are enhancing our synthetic monitoring dashboards to improve visibility of regional service performance deviations.  * We are conducting rigorous connection-recovery and system testing in our lower environments to validate application resilience under loaded states.  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.  If you have further questions or concerns, please visit our [Support website](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F). We appreciate your patience during this incident and value the trust you place in Anaplan.

Jul 21, 2026 · resolved Jul 21

On July 21, 2026, between 14:15 UTC and 14:50 UTC, the us5: Cloud - US East region experienced a disruption to scheduled CloudWorks™ integrations. During this window, automated workflows could not be triggered, and users may have experienced difficulties accessing integration services.  **Root cause**   The issue was triggered by a brief interruption in the underlying storage systems following a system release rollback. This led to a loss of connectivity within the integration scheduler system, which prevented scheduled tasks from being successfully queued or triggered.  **Recovery**   Our engineering team identified the issue and took immediate action. We verified system connectivity as the underlying services recovered automatically, and we executed test integrations to validate scheduled workflows. These validation checks confirmed that all scheduling mechanisms had safely resumed normal operations without requiring a system restart. By 14:50 UTC, the issue was fully resolved.  **Corrective and preventative actions**  * We are conducting a deep-dive investigation into system performance during rollback operations to ensure stability under high-load conditions.  * We are implementing enhanced health checks for the integration scheduler to ensure it reaches a "ready" state before traffic is routed during rollbacks.  * We are updating our deployment processes to include automated validation of task queue depth immediately following any regional update or rollback.  * We are updating our resource sizing documentation for this service with recommended request/limit values to ensure sufficient capacity for deployment and rollback operations.  We apologize for any impact this issue may have had on your business operations. We are strengthening our systems and procedures to avoid disruptions to your business and users.  If you have further questions or concerns, please visit our [Support](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F) website. We appreciate your patience during this incident and value the trust you place in Anaplan.

Jul 14, 2026 · resolved Jul 14

On July 14, 2026, at 19:55 UTC, customers in our us7: Cloud - US West region experienced delays and failures in CloudWorks™ integration job processing. Integration jobs that were scheduled to run in this region did not complete as expected, resulting in a processing backlog that was cleared once service was fully restored.  Root cause   A back-end component supporting the CloudWorks™ service temporarily exhausted its available memory, leading to a brief connectivity disruption. Although the database recovered immediately, the CloudWorks™ processing components retained inactive connections and were unable to automatically reconnect. This prevented integration jobs from completing and caused a queue of scheduled tasks to accumulate.  Recovery   Our engineering team identified the issue and took immediate action. The team restarted the CloudWorks™ processing components to clear all stale and inactive connections. To quickly clear the backlog of pending integration jobs, we temporarily increased the processing capacity of the components. After verifying that integration jobs were completed normally and the backlog had been fully processed, we returned the system to its original capacity. By 21:14 UTC, the issue was fully resolved.  Corrective and preventative actions   We are implementing the following actions to prevent recurrence:   * **Memory allocation increase:** We are increasing the memory allocation for the back-end component in us7. This reduces the likelihood of a similar memory pressure event occurring in the future.  * **Background process optimization:** We've disabled certain background metric collection processes that were contributing unnecessary load to the back-end component. This further lowers the risk of memory pressure building over time.  * **Resilience testing:** Our engineering teams are running controlled tests in non-production environments to better understand how the CloudWorks™ service behaves during brief connectivity disruptions. This work will help us improve the service's ability to recover automatically — without requiring manual intervention — should a similar event occur in the future.  We apologize for the impact this issue has had on your operations. We are committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

Is Anaplan down right now?

No — Anaplan is up. All systems operational as of Aug 19, 10:41 PM UTC.

What is Anaplan's current status?

Anaplan: All Systems Operational. Alert24 checks Anaplan's status page continuously and can notify you the moment it changes.

How do I get alerted when Anaplan goes down?

Alert24 monitors Anaplan and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.