Is Arista CloudVision down?

We are experiencing high device streaming latency on this affected cluster. Some impact may be user visible, such as: - A delay in processing streamed device data. Some events such as "Device stopped streaming" or "Streaming Latency Breached Threshold" may fire as a result of this. In this case, the device updates are behind schedule and will be processed with some delay during the impact window. - There may be some stale data, or sporadic timeouts viewing parts of the UI. - Some provisioning features may be delayed or timeout due to the high latency. We are currently investigating the issue and working on mitigation. Thank you for your patience.

We identified the source of the problem and the data ingestion latency has been resolved.

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.

We are continuing to investigate this issue.

We are continuing to investigate this issue.

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.

We are continuing to investigate this issue.

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.

We are testing the fixes in the staging environment.

We are applying fixes and are selectively enabling Network Provisioning.

We have restored Network Provisioning operation for select clusters. We will provide another update no later than May 30th, 11:00pm 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.

We are continuing to restore Network Provisioning operation for select clusters. We will provide another update no later than May 31st, 11:00am 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.

We are continuing to restore Network Provisioning operation for select clusters. We will provide another update no later than May 31st, 11:00pm 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.

We are continuing to monitor. No change in operational status for Network Provisioning features since last update.

We are continuing to monitor. No change in operational status for Network Provisioning features since last update.

We are continuing to monitor. No change in operational status for Network Provisioning features since last update.

We are continuing to monitor. No change in operational status for Network Provisioning features since last update.

We are continuing to monitor. No change in operational status for Network Provisioning features since last update.

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.

This incident has been resolved.

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

We are investigating reports of unexpected configuration changes in Studios workspaces following the provisioning upgrade yesterday and determining remediation actions. Please refrain from using Studios provisioning features at this time.

A fix has been identified and we are in the process of updating all affected regions.

A fix has been implemented and we are monitoring the results.

We are continuing to monitor for any further issues.

This incident has been resolved.

We are aware of a subset of users experiencing issues logging in with SSO/SAML/OAuth. We are currently investigating the issue.

A fix has been implemented and we are monitoring the results.

This incident has been resolved. We will follow up with a postmortem.

We experienced high device streaming latency on this affected cluster. Some impact may be user visible, such as: - A delay in processing streamed device data. Some events such as "Device stopped streaming" or "Streaming Latency Breached Threshold" may fire as a result of this. In this case, the device updates are behind schedule and will be processed with some delay during the impact window. - There may be some stale data, or sporadic timeouts viewing parts of the UI. - Some provisioning features may be delayed or timeout due to the high latency. This was due to an internal component upgrade in our cloud environment; we continue to work on decreasing the impact of this upgrade process. Thank you for your patience.