Anaplan Status Page

Aug 27, 2026 · resolved Aug 27

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.

Aug 15, 2026 · resolved Aug 15

On August 15, 2026, from 03:16 UTC to 08:23 UTC, customers in our eu2: Data Center - Germany region experienced a service interruption that prevented access to the Anaplan platform. During this time, a local infrastructure failure affected the region's ability to connect to external services, resulting in a loss of platform availability.  **Root cause**  The disruption was caused by an environmental failure at our vendor's third-party facility in Frankfurt, Germany. A leak in the facility's cooling system led to localized overheating, which triggered automatic safety shutdowns of critical network equipment. Escaped water also damaged localized power distribution systems within the facility, disabling network devices. This combined power and cooling failure prevented the system from resolving external addresses and completing outbound requests in this region.  **Recovery**  Because the facility's environmental conditions made the area unsafe to enter, our vendor was delayed in assessing and repairing the affected equipment. As a result, our engineering team deployed an emergency change to reroute traffic through an alternate regional network path, bypassing the impaired facility and region. This successfully restored full external connectivity and name resolution, and platform access was fully restored by 08:23 UTC.  The facility’s operator and our vendor continued recovery work over the following days, with full restoration confirmed by August 18. We maintained our emergency routing throughout that period to keep service stable while the vendor completed repairs.  **Corrective and preventative actions**  We are implementing the following measures to strengthen resilience and reduce the risk of a similar disruption:  * We are adding a layer that automatically redirects traffic to alternate geographic locations during a localized outage, with no manual intervention required.  * We are enabling cached records to continue serving traffic when the path to external resolvers is unavailable, so a connectivity loss to external services no longer prevents platform access when a regional event occurs.  * We are working with our third-party facility and network providers to review their standards for critical power and cooling systems and ensure stronger preventative safeguards are in place.  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 our Support team.

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.

Is Anaplan down right now?

No — Anaplan is up. All systems operational as of Aug 28, 1:49 AM 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.