Anaplan Status Page

Jul 2, 2026 · resolved Jul 2

On July 1, 2026, at approximately 23:52 UTC, our monitoring systems detected a service disruption impacting customers in the me1: Cloud – Middle East and eu5: Cloud — Europe regions. During this time, affected customers were unable to log in to the platform. Service was restored at 03:21 UTC **Root cause**  The disruption originated from a planned network configuration change to our internal name resolution infrastructure. A misconfiguration was introduced as part of the change that left an underlying routing conflict in place. This caused return traffic for internal name lookups to take an incorrect path during routine network activity. As a result, internal name resolution began failing for the two affected regions. This prevented the authentication flow from completing and stopped customers from logging in.  **Recovery**  On detection at 23:52 UTC, our engineering team and our infrastructure partner began investigating in parallel. Because internal name resolution issues can present themselves in several diverse ways, the team worked through multiple lines of inquiry before isolating the specific routing conflict responsible. Once identified, we rolled back the recent change to restore the previous known-good routing configuration. Connectivity recovered progressively as the rollback propagated, and by 03:21 UTC, authentication was fully restored for both affected regions.   **Corrective and preventative actions**  We are implementing the following actions to prevent a recurrence:  * We are adding pre-change validation that specifically detects the class of routing conflict responsible for this incident. This closes off the underlying configuration issue before any similar change can reach the environment.  * We are re-architecting the affected routing setup to prevent this class of misconfiguration from being introduced again. This removes the underlying issue at the source.  * We are improving our monitoring for the internal name resolution paths between our cloud environments. This shortens the time to detect and resolve this class of issue. **Closing**  We apologize for the impact this disruption has had on your operations. The corrective actions above are focused on preventing a recurrence of any similar issue in the future. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

Jun 22, 2026 · resolved Jun 22

On June 22, 2026, at 07:20 UTC, we became aware of an issue affecting our us7: Cloud – US region. Customers experienced difficulties loading models, with impact beginning at approximately 05:12 UTC. CloudWorks™ integrations in the region were also unable to run during this period. Customers with active workspace sessions weren't affected. However, any workspace that was unloaded during this time couldn't be loaded until service was restored. Full service was restored at 10:21 UTC.  **Root cause**  A component that manages active workspace resources in the us7 region encountered an unexpected fault and restarted. On restart, the component entered a state where it appeared to be operating normally but couldn't process new workspace requests. Our systems normally recover automatically from this kind of state, but in this case the fault wasn't detected by our recovery processes. We intervened manually and performed a corrective restart of the component, which restored normal operation.  **Recovery**  We conducted a thorough investigation of the platform and identified the source of the issue. We performed a targeted reset of the resource scheduling services to clear the pending connections and restore normal communication. Once communication was re-established at 08:48 UTC, the platform began successfully assigning resources and loading models.  To handle the accumulated backlog of scheduled integrations, we scaled up the processing capacity for CloudWorks™. By 10:21 UTC, the backlog had finished processing, and the issue was fully resolved.  **Corrective and preventative actions**  We're implementing the following actions to prevent recurrence:  * We're deploying enhanced automated monitoring specifically designed to detect the condition seen in this incident, where a component appears operational but isn't processing requests. This closes the detection gap that extended the impact of this issue.  * We're developing automated self-healing for the resource scheduling component, so that a corrective restart can be performed automatically without engineering intervention. This directly addresses the failure mode that caused this incident.  * We're streamlining our scaling procedures for CloudWorks™, so that integration processing capacity can be expanded more rapidly during recovery. This shortens the time to clear integration backlogs following incidents like this one.  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://support.anaplan.com/) website. We appreciate your patience during this incident and value the trust you place in Anaplan.

Jun 17, 2026 · resolved Jun 17

On June 17, 2026, at 06:50 UTC, we became aware of an issue affecting a subset of workspaces in our eu4: Cloud - Europe region. Customers with affected workspaces were unable to load models, seeing persistent loading screens or errors when opening their work. CloudWorks™ integrations in the region also experienced a period of degradation, from approximately 05:20 UTC to 06:26 UTC, because of the same underlying issue. The impact was limited to a specific subset of workspaces — all other regions, and many workspaces in eu4: Cloud - Europe, continued to operate normally. Full service for the affected workspaces was restored at 10:00 UTC.   Root cause  The affected workspaces ran on a previous storage configuration in the eu4 region. Over time, a storage directory used by these workspaces accumulated a large number of small temporary files. The directory reached its operational limit and could no longer accept new file operations. This prevented models from loading for customers whose workspaces were running on this configuration.  Recovery  Our engineering team cleared the accumulated temporary files, which provided immediate relief. We then moved all affected workspaces from the old configuration to the new configuration through an automated process. We checked that model loading was restored through testing. By 10:00 UTC, the issue was fully resolved. On the same day, we implemented a change across the eu4 region to make sure no workspace can be directed to the old configuration.  Corrective and preventative actions  We've taken the following actions to address this incident and prevent it from happening again:  1. We've deployed an update across all regions that prevents any workspace from being directed to the older storage configuration. This eliminates the specific configuration condition that caused this incident.  2. We're decommissioning the older storage configuration. This permanently removes the configuration that caused this incident.  3. We’re strengthening our automated validation checks to confirm that workspaces are running on the correct configuration. This catches any configuration mismatch before it can cause customer impact.  4. We're implementing automated cleanup rules for the temporary files involved in this incident. This prevents storage directories from reaching operational limits and supports faster automatic recovery.  Closing  We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

Jun 11, 2026 · resolved Jun 12

**June 8–12, 2026 Platform Disruptions** On June 8, 2026, at 11:05 UTC, our monitoring detected a brief drop in incoming traffic across the Anaplan platform, with automated monitoring checks failing across all affected regions \(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\). Over the four days, a series of related disruptions affected the same regions. Customers experienced intermittent difficulties logging in, opening models, and running integrations. The platform was fully stabilized on June 11, 2026, at 18:12 UTC. These disruptions are linked to our previously communicated infrastructure modernization program. On the weekend of June 6, we migrated our control plane, the part of the platform that directs how traffic is routed between services. This was the most complex of the planned migration weekends, and it was completed successfully, as had the two previous migration weekends. The issues described in this report emerged in the days following that migration. This report covers the seven linked incidents that occurred between June 8 and June 11, 2026. **Root cause** As part of our infrastructure modernization program, on the weekend of June 6, we completed a successful migration of our control plane. In the days that followed, we observed two discrete network-hardware issues that interacted to drive these disruptions. _Issue 1: Media Access Control \(MAC\) flapping \(June 8–9\)_ Every device on a network has a MAC address, a unique hardware identifier that network switches use to route traffic to the correct destination. In our environment, the MAC addresses involved are virtual — assigned to logical network gateways rather than to fixed physical hardware — which allows them to legitimately move between hosts as part of normal operation. MAC flapping occurs when a switch sees the same MAC address appearing on two different physical ports in rapid succession, forcing it repeatedly to update its routing tables. This briefly slows or interrupts traffic. For customers, this surfaced as a brief, self-recovering instability. Short bursts of load and intermittent errors appeared and cleared on their own within minutes. The trigger for this behavior was the specific way live production traffic interacted with the new post-migration network. To resolve the issue, we scaled capacity, engaged our vendor, and deployed configuration changes to contain the impact. _Issue 2: network card driver defect \(June 10–11\)_ Once the first set of mitigations were in place, we identified a second issue: A defect in the network card driver, which is the software that controls how a network card sends and receives data. The defect affected fewer than 0.005% of the cards in our estate. Those cards failed randomly and unpredictably, dropping traffic while still appearing healthy to our monitoring systems. This is known as a "gray failure" condition, because the affected components don’t flag themselves as broken. The cards sat in the part of the network that routes traffic between the regions impacted. This resulted in failures that cascaded across the platform and drove disruptions on June 10 and June 11. The defect hadn't been observed in previous migrations or in any other environment, and there were no indicators in pre-deployment testing. The gray failure pattern was also what initially masked the defect as a load issue, until further investigation pointed us to the driver itself. We engaged our vendor, who confirmed the defect. Working closely with them, we rapidly prepared, tested, and deployed the patch to the affected hosts on the evening of June 11, UTC. After that, the platform stabilized. **Recovery** From the first occurrence on June 8 through to permanent resolution on June 11, our engineering team led a continuous, round-the-clock response, working closely with our vendor to identify, diagnose, and resolve the underlying defect. We deployed configuration mitigations, repeatedly rerouted traffic between hosts and across alternative network paths, and scaled out capacity to restore service to customers as quickly as possible while the underlying defect was being addressed. The seven linked incidents and their impact windows were: * **June 8, 2026, 11:00–11:20 UTC** — A short network disruption from the initial MAC flapping event caused intermittent login failures and slow page loads. For most customers, this appeared as a brief 6-minute blip and recovered automatically. Some basic authentication users experienced a longer impact and needed to start a new browser session, with full recovery by 11:20 UTC. * **June 9, 2026, 11:05–11:29 UTC** — A recurrence of the same MAC flapping condition caused a similar brief disruption. Again, most customers experienced only a short blip of around 6 minutes, with basic authentication users seeing a longer impact. We applied scaling changes to address the issue. * **June 10, 2026, 11:02–12:40 UTC** — Customers across all affected regions experienced a loss of access to the platform for approximately 98 minutes. We worked with the vendor and applied configuration changes to address the issue. * **June 10–11, 2026, 23:06–00:04 UTC** — A disruption of approximately 58 minutes, caused when the network card defect affected the backup host that traffic had been moved to. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 03:43–05:20 UTC** — A disruption of approximately 97 minutes, as the next backup host was affected by the same defect. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 11:10–13:02 UTC** — A further recurrence of the network traffic surge caused customers to experience slow or failed access to the platform. We restored service by applying an underlying configuration change. * **June 11, 2026, 17:04–17:48 UTC** — A final disruption of approximately 44 minutes during which we moved traffic to a host running the updated network card driver. The platform was fully stabilized at 18:12 UTC on June 11, 2026, once traffic was successfully moved to a host running the updated network card driver. We then applied the same update to a second host for resilience. Monitoring continued through to midday Friday before the incident was closed. CloudWorks™ experienced a backlog of queued jobs during and immediately after each disruption. Our engineering team scaled out CloudWorks capacity to accelerate processing, and the backlog was fully cleared shortly after each recovery. **Corrective and preventative actions** The control plane migration that preceded these disruptions was a one-time, foundational piece of work. The actions below reflect the learnings we are carrying forward from the event to further strengthen the platform. 1. The updated network card driver has been rolled out across all hosts matching the affected hardware profile, in every region. This removes the underlying defect from our infrastructure, even though it hasn't been observed in any other region. 2. The conditions that allowed MAC flapping to surface as customer-visible instability have been addressed at multiple layers. Configuration changes have been deployed in the affected regions. The underlying network configuration has been standardized across the wider production estate, and we have tuned the network behavior that triggered the initial event. 3. During the incident, our engineering team deployed dedicated alerting in real time for the specific network conditions causing the disruptions, enabling faster detection and intervention throughout the response. We are continuing to strengthen proactive monitoring and early-warning detection across post-release windows, so that emerging anomalies are surfaced and investigated before they escalate into customer-visible disruptions. 4. The remaining infrastructure update that supports the network card fix is being completed across our other environments. This brings the full benefit of the fix to every part of our infrastructure. **What's next** One final migration weekend is scheduled for June 20, 2026. After this, the migration phase of the infrastructure modernization program is complete. **Closing** We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).

Jun 11, 2026 · resolved Jun 11

**June 8–12, 2026 Platform Disruptions** On June 8, 2026, at 11:05 UTC, our monitoring detected a brief drop in incoming traffic across the Anaplan platform, with automated monitoring checks failing across all affected regions \(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\). Over the four days, a series of related disruptions affected the same regions. Customers experienced intermittent difficulties logging in, opening models, and running integrations. The platform was fully stabilized on June 11, 2026, at 18:12 UTC. These disruptions are linked to our previously communicated infrastructure modernization program. On the weekend of June 6, we migrated our control plane, the part of the platform that directs how traffic is routed between services. This was the most complex of the planned migration weekends, and it was completed successfully, as had the two previous migration weekends. The issues described in this report emerged in the days following that migration. This report covers the seven linked incidents that occurred between June 8 and June 11, 2026. **Root cause** As part of our infrastructure modernization program, on the weekend of June 6, we completed a successful migration of our control plane. In the days that followed, we observed two discrete network-hardware issues that interacted to drive these disruptions. _Issue 1: Media Access Control \(MAC\) flapping \(June 8–9\)_ Every device on a network has a MAC address, a unique hardware identifier that network switches use to route traffic to the correct destination. In our environment, the MAC addresses involved are virtual — assigned to logical network gateways rather than to fixed physical hardware — which allows them to legitimately move between hosts as part of normal operation. MAC flapping occurs when a switch sees the same MAC address appearing on two different physical ports in rapid succession, forcing it repeatedly to update its routing tables. This briefly slows or interrupts traffic. For customers, this surfaced as a brief, self-recovering instability. Short bursts of load and intermittent errors appeared and cleared on their own within minutes. The trigger for this behavior was the specific way live production traffic interacted with the new post-migration network. To resolve the issue, we scaled capacity, engaged our vendor, and deployed configuration changes to contain the impact. _Issue 2: network card driver defect \(June 10–11\)_ Once the first set of mitigations were in place, we identified a second issue: A defect in the network card driver, which is the software that controls how a network card sends and receives data. The defect affected fewer than 0.005% of the cards in our estate. Those cards failed randomly and unpredictably, dropping traffic while still appearing healthy to our monitoring systems. This is known as a "gray failure" condition, because the affected components don’t flag themselves as broken. The cards sat in the part of the network that routes traffic between the regions impacted. This resulted in failures that cascaded across the platform and drove disruptions on June 10 and June 11. The defect hadn't been observed in previous migrations or in any other environment, and there were no indicators in pre-deployment testing. The gray failure pattern was also what initially masked the defect as a load issue, until further investigation pointed us to the driver itself. We engaged our vendor, who confirmed the defect. Working closely with them, we rapidly prepared, tested, and deployed the patch to the affected hosts on the evening of June 11, UTC. After that, the platform stabilized. **Recovery** From the first occurrence on June 8 through to permanent resolution on June 11, our engineering team led a continuous, round-the-clock response, working closely with our vendor to identify, diagnose, and resolve the underlying defect. We deployed configuration mitigations, repeatedly rerouted traffic between hosts and across alternative network paths, and scaled out capacity to restore service to customers as quickly as possible while the underlying defect was being addressed. The seven linked incidents and their impact windows were: * **June 8, 2026, 11:00–11:20 UTC** — A short network disruption from the initial MAC flapping event caused intermittent login failures and slow page loads. For most customers, this appeared as a brief 6-minute blip and recovered automatically. Some basic authentication users experienced a longer impact and needed to start a new browser session, with full recovery by 11:20 UTC. * **June 9, 2026, 11:05–11:29 UTC** — A recurrence of the same MAC flapping condition caused a similar brief disruption. Again, most customers experienced only a short blip of around 6 minutes, with basic authentication users seeing a longer impact. We applied scaling changes to address the issue. * **June 10, 2026, 11:02–12:40 UTC** — Customers across all affected regions experienced a loss of access to the platform for approximately 98 minutes. We worked with the vendor and applied configuration changes to address the issue. * **June 10–11, 2026, 23:06–00:04 UTC** — A disruption of approximately 58 minutes, caused when the network card defect affected the backup host that traffic had been moved to. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 03:43–05:20 UTC** — A disruption of approximately 97 minutes, as the next backup host was affected by the same defect. We restored connectivity by moving traffic onto an alternative network path. * **June 11, 2026, 11:10–13:02 UTC** — A further recurrence of the network traffic surge caused customers to experience slow or failed access to the platform. We restored service by applying an underlying configuration change. * **June 11, 2026, 17:04–17:48 UTC** — A final disruption of approximately 44 minutes during which we moved traffic to a host running the updated network card driver. The platform was fully stabilized at 18:12 UTC on June 11, 2026, once traffic was successfully moved to a host running the updated network card driver. We then applied the same update to a second host for resilience. Monitoring continued through to midday Friday before the incident was closed. CloudWorks™ experienced a backlog of queued jobs during and immediately after each disruption. Our engineering team scaled out CloudWorks capacity to accelerate processing, and the backlog was fully cleared shortly after each recovery. **Corrective and preventative actions** The control plane migration that preceded these disruptions was a one-time, foundational piece of work. The actions below reflect the learnings we are carrying forward from the event to further strengthen the platform. 1. The updated network card driver has been rolled out across all hosts matching the affected hardware profile, in every region. This removes the underlying defect from our infrastructure, even though it hasn't been observed in any other region. 2. The conditions that allowed MAC flapping to surface as customer-visible instability have been addressed at multiple layers. Configuration changes have been deployed in the affected regions. The underlying network configuration has been standardized across the wider production estate, and we have tuned the network behavior that triggered the initial event. 3. During the incident, our engineering team deployed dedicated alerting in real time for the specific network conditions causing the disruptions, enabling faster detection and intervention throughout the response. We are continuing to strengthen proactive monitoring and early-warning detection across post-release windows, so that emerging anomalies are surfaced and investigated before they escalate into customer-visible disruptions. 4. The remaining infrastructure update that supports the network card fix is being completed across our other environments. This brings the full benefit of the fix to every part of our infrastructure. **What's next** One final migration weekend is scheduled for June 20, 2026. After this, the migration phase of the infrastructure modernization program is complete. **Closing** We apologize for the impact this issue has had on your operations. We're 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 Jul 13, 11:49 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.