Arista CloudVision incident
Network Provisioning - Device is present in an unexpected container
Arista CloudVision experienced a major incident on May 29, 2026 affecting Network Provisioning - Studios and Network Provisioning - Studios and 1 more component, lasting 5d 2h. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating May 29, 2026, 08:24 PM UTC
We are investigating reports devices showing up unexpected containers if Network Provisioning work flows are used. Please refrain from using Network Provisioning features at this time.
- investigating May 29, 2026, 08:25 PM UTC
We are continuing to investigate this issue.
- investigating May 29, 2026, 09:02 PM UTC
We are continuing to investigate this issue.
- investigating May 29, 2026, 09:56 PM UTC
Please do not use any of the Network Provisioning UI, workflows, or provisioning even if you see unexpected configurations being displayed. Please do not execute any changes unless your device configurations are strictly only managed by Studios. We are continuing to root cause.
- investigating May 29, 2026, 11:01 PM UTC
We are continuing to investigate this issue.
- investigating May 30, 2026, 04:32 AM UTC
The team has an understanding of the issue, but due to its complex nature, we are taking additional testing and steps to ensure our proposed fixes will be safe to apply. We will provide another update no later than May 30th, 11:00 UTC.
- identified May 30, 2026, 10:57 AM UTC
We are testing the fixes in the staging environment.
- identified May 30, 2026, 05:35 PM UTC
We are applying fixes and are selectively enabling Network Provisioning.
- identified May 30, 2026, 06:36 PM UTC
We have restored Network Provisioning operation for select clusters. We will provide another update no later than May 30th, 11:00pm UTC.
- identified May 30, 2026, 10:56 PM UTC
We are continuing to restore Network Provisioning operation for select clusters. We will provide another update no later than May 31st, 5:00am UTC.
- identified May 31, 2026, 04:57 AM UTC
We are continuing to restore Network Provisioning operation for select clusters. We will provide another update no later than May 31st, 11:00am UTC.
- identified May 31, 2026, 10:57 AM UTC
We are continuing to restore Network Provisioning operation for select clusters. We will provide another update no later than May 31st, 05:00pm UTC.
- identified May 31, 2026, 05:18 PM UTC
We are continuing to restore Network Provisioning operation for select clusters. We will provide another update no later than May 31st, 11:00pm UTC.
- monitoring May 31, 2026, 05:55 PM UTC
Network Provisioning is restored for all CVaaS service regions. Any customers that have been directly engaged with us for additional assistance required would’ve been contacted already. If you have not been reached out by us directly, Network Provisioning features have been restored for usage.
- monitoring May 31, 2026, 10:53 PM UTC
We are continuing to monitor. No change in operational status for Network Provisioning features since last update.
- monitoring Jun 01, 2026, 04:59 AM UTC
We are continuing to monitor. No change in operational status for Network Provisioning features since last update.
- monitoring Jun 01, 2026, 10:55 AM UTC
We are continuing to monitor. No change in operational status for Network Provisioning features since last update.
- monitoring Jun 01, 2026, 05:00 PM UTC
We are continuing to monitor. No change in operational status for Network Provisioning features since last update.
- monitoring Jun 01, 2026, 10:56 PM UTC
We are continuing to monitor. No change in operational status for Network Provisioning features since last update.
- monitoring Jun 02, 2026, 03:37 AM UTC
We are continuing to monitor through this week but this is our final status update. Currently, our teams are working on postmortem that can be shared. Thank you for your patience.
- resolved Jun 04, 2026, 12:50 AM UTC
This incident has been resolved.
- postmortem Jun 04, 2026, 12:50 AM UTC
**Incident Report: CVaaS Service Disruption - May 29, 2026** On May 29th, 2026, CloudVision as-a-Service delivered a software change for a set of services that provide the Network Provisioning workflows in the product. All services regions were impacted by this Network Provisioning feature update. This update introduced a critical bug across all service regions. As a result, customers utilizing the Network Provisioning workflows \(see [https://www.arista.io/help/articles/provisioning-network-provisioning#network-provisioning](https://www.arista.io/help/articles/provisioning-network-provisioning#network-provisioning)\) may have experienced instances where devices were mapped to the incorrect containers in the network provisioning hierarchy, creating a risk that unintended configuration states could be applied if customers then attempted to roll out additional changes to devices. The Network Provisioning workflows were disabled while we recovered from the issue, meaning that customers could not make any changes to their network configuration during this time. Customers only defining their network configuration using Studios workflows \(see [https://www.arista.io/help/articles/provisioning-studios](https://www.arista.io/help/articles/provisioning-studios)\) were not impacted. The software change that caused this issue was rolled back on May 29th, 2026. The delay in mitigation was due to gaps in our automated monitoring systems. FAQ: * _Did this bug cause a network outage for customers?_ No. * _Was there any data loss?_ No. * Was overall CloudVision service availability impacted?No. * _Are there any additional steps to recovery?_ No; the vast majority of impacted customers were recovered without requiring customer intervention. At this moment if you have not been directly contacted by us, no further action is required from you. **Root Cause** The bug was due to logic applied to an incorrect data state within the Network Provisioning feature. This caused an incorrect device container mapping during the device state reconciliation phase. This was not caught during testing or during the post deployment evaluation phase in various environments prior to being released to production. Additionally, the rollout strategy used in the continuous delivery applicable for this particular set of services allowed the bug to propagate quickly across all CloudVision as-a-Service regions. **Our Response** Once the bug was identified on May 29th, 2026, our team rolled back the update responsible within approximately a five hour period on all production regions. In addition, API usage restrictions were established as a protective measure against customers that may inadvertently execute a configuration change on their network without knowledge of this bug and device state change. Between May 29th and June 1st, 2026, our team engaged in continuous efforts to restore services for all affected customers and devices. The majority of these recovery operations were successfully concluded by May 30th, 2026. Throughout this period, we maintained regular updates on Statuspage to keep our customers informed regarding our progress. We understand a disruption of this nature is unacceptable for our customers. We are conducting a full review of design, testing, validation, delivery, monitoring, and incident response as part of the postmortem review, and we are committed to ensuring we do not run into incidents of this nature in the future. Thank you for using CloudVision as-a-Service.