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:
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.
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.