Arista CloudVision Outage History

Started Oct 20, 2026, 06:21 AM UTC· resolved Oct 20, 2026, 04:53 PM UTC

1. investigating Oct 20, 2026, 06:21 AM UTC

   We are currently investigating this issue.

2. identified Oct 20, 2026, 06:47 AM UTC

   We are currently experiencing a sitewide outage due to underlying provider outages. Our team is actively working with the dependencies to resolve the issue.

3. identified Oct 20, 2026, 07:57 AM UTC

   We are currently experiencing a sitewide outage due to underlying provider outages. Our team is actively working with the dependencies to resolve the issue.

4. identified Oct 20, 2026, 08:57 AM UTC

   We are currently experiencing a sitewide outage due to underlying provider outages. Our team is actively working with the dependencies to resolve the issue.

5. identified Oct 20, 2026, 09:52 AM UTC

   We are currently experiencing a sitewide outage due to underlying provider outages. Our team is actively working with the dependencies to resolve the issue.

6. identified Oct 20, 2026, 10:56 AM UTC

   We are continuing to work on the recovery. Thank you for your patience.

7. identified Oct 20, 2026, 11:55 AM UTC

   We are actively working on cluster restoration. Thank you for your patience.

8. identified Oct 20, 2026, 12:47 PM UTC

   We are re-enabling device streaming back into the region.

9. identified Oct 20, 2026, 12:55 PM UTC

   We have restored Login into the region.

10. identified Oct 20, 2026, 12:58 PM UTC

    All functionality is restored but we are working on final stabilization activities.

11. identified Oct 20, 2026, 01:32 PM UTC

    Events are fully operational.

12. monitoring Oct 20, 2026, 01:49 PM UTC

    UK region is fully operational. We are going to continue monitoring. Once monitoring period is over, we will follow up with the official postmortem.

13. resolved Oct 20, 2026, 04:53 PM UTC

    The incident has been resolved, we are still working on our postmortem analysis and will follow up with a detailed RCA soon.

Read the full incident report →

Started Sep 24, 2026, 09:25 PM UTC· resolved Sep 24, 2026, 09:25 PM UTC

1. resolved Sep 24, 2026, 10:18 PM UTC

   We experienced high device streaming latency on the us-central1-b 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. The issue has been fully resolved at 2:45 PM PDT. Thank you for your patience.

Read the full incident report →

Started Sep 09, 2026, 08:02 PM UTC· resolved Sep 10, 2026, 04:03 AM UTC

1. investigating Sep 09, 2026, 08:02 PM UTC

   We are currently investigating issue that is impacting NetDL platform on this service region.

2. identified Sep 09, 2026, 08:11 PM UTC

   We've identified the issues and in the process of recovery

3. monitoring Sep 09, 2026, 08:38 PM UTC

   We have recovered from the initial trigger of the incident. We are monitoring full recovery.

4. monitoring Sep 09, 2026, 09:10 PM UTC

   We have fully recovered, but we are continuing to monitor and proceed with cleanup activities.

5. identified Sep 09, 2026, 09:56 PM UTC

   Unfortunately we had fully recovered, but underlying conditions have reforced the same impact. Our team is currently working on recovery.

6. monitoring Sep 09, 2026, 10:12 PM UTC

   We have recovered from the re-trigger of the incident. We are monitoring.

7. monitoring Sep 09, 2026, 10:32 PM UTC

   We have fully recovered, but we are continuing to monitor and proceed with cleanup activities.

8. monitoring Sep 09, 2026, 10:56 PM UTC

   We are continuing to monitor until we have confirmed continued stability for several more hours.

9. resolved Sep 10, 2026, 04:03 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Aug 28, 2026, 05:39 PM UTC· resolved Aug 28, 2026, 08:40 PM UTC

1. investigating Aug 28, 2026, 05:39 PM UTC

   We are aware of ongoing disruption for cv-prod-us-central1-c. Our team is currently assessing impact and mitigation.

2. identified Aug 28, 2026, 05:49 PM UTC

   We've identified the issue, and currently mitigating impact. The following is the list of impact that would've been visible as a user: - Device reachability, and streaming to cv-prod-us-central1-c - Ability to make device provisioning changes (i.e. Studios, Network Provisioning Classic) - Delays in dashboards or live status views

3. monitoring Aug 28, 2026, 06:24 PM UTC

   We've fully recovered and monitoring.

4. resolved Aug 28, 2026, 08:40 PM UTC

   This incident arose from unexpected localized network partitioning due to underlying conditions. Our systems automatically detected the event in <5m of the start of the impact, and began recovery, with minimal manual intervention involved. We are analyzing further hardening against the underlying conditions of this nature.

Read the full incident report →

Started Aug 12, 2026, 06:51 PM UTC· resolved Aug 12, 2026, 07:03 PM UTC

1. investigating Aug 12, 2026, 06:51 PM UTC

   We are investigating an infrastructure degradation affecting CloudVision services. Customers may experience delayed processing, increased latency or intermittent errors. The team is actively working to mitigate the issue.

2. resolved Aug 12, 2026, 07:03 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Aug 12, 2026, 04:19 PM UTC· resolved Aug 13, 2026, 05:25 AM UTC

1. investigating Aug 12, 2026, 04:19 PM UTC

   We are currently investigating an increase in generated "Device Experiencing Streaming Issues" events. The issue started around August 8 and affects random sets of devices.

2. investigating Aug 12, 2026, 06:23 PM UTC

   We continue to investigate the root cause of this issue. We have determined that the disruptions occur at hourly intervals, impacting a randomized subset of devices. We have deployed an initial mitigation that will help affected devices recover more quickly and reduce the volume of "CloudVision Not Receiving State from Device" alerts. Please note that while this mitigation is in place, affected devices will continue to experience elevated streaming latency. We will provide another update as soon as more information is available.

3. investigating Aug 12, 2026, 06:52 PM UTC

   We have determined that the initial mitigation deployed in our previous update did not have the intended effect. Devices will continue to experience elevated streaming latency and generate "CloudVision Not Receiving State from Device" events. Our team is continuing to investigate the root cause and find other potential mitigations.

4. investigating Aug 12, 2026, 10:45 PM UTC

   We have deployed a second mitigation. Our team is monitoring the impact and continuing to root cause the problem.

5. monitoring Aug 13, 2026, 12:20 AM UTC

   The mitigation is holding. We are transitioning to monitoring and further root causing.

6. resolved Aug 13, 2026, 05:25 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Aug 06, 2026, 10:45 AM UTC· resolved Aug 06, 2026, 11:47 AM UTC

1. investigating Aug 06, 2026, 10:45 AM UTC

   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.

2. resolved Aug 06, 2026, 11:47 AM UTC

   The issue has been identified and a mitigation has been put in place. Streaming latencies have returned to their expected level.

Read the full incident report →

Started Jul 15, 2026, 09:45 PM UTC· resolved Jul 15, 2026, 09:45 PM UTC

1. investigating Jul 15, 2026, 09:45 PM UTC

   We are currently investigating an issue with Change Control features for a subset of tenants.

2. resolved Jul 15, 2026, 09:45 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 10, 2026, 06:25 PM UTC· resolved Jul 10, 2026, 06:46 PM UTC

1. monitoring Jul 10, 2026, 06:25 PM UTC

   We are aware of the brief data ingestion delay into NetDL experienced on cv-prod-us-central1-c platform. The issue has been identified, and also resolved. We are continuing to monitor.

2. monitoring Jul 10, 2026, 06:46 PM UTC

   We are continuing to monitor for any further issues.

3. resolved Jul 10, 2026, 06:46 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 07, 2026, 10:58 PM UTC· resolved Jul 13, 2026, 11:54 PM UTC

1. monitoring Jul 07, 2026, 10:58 PM UTC

   Hello CVaaS Users, This is a courtesy notice to keep our users on service region cv-prod-us-central1-b informed. Our team continues to monitor as follow up to mitigations for the incident on June 26th (https://status.arista.io/incidents/5vx7cvb07k7d). At present, cv-prod-us-central1-b service region is fully operational. We expect users to be able to continue using Provisioning and Telemetry features as normal. No other service regions are impacted by this incident. Thank you for using CVaaS.

2. resolved Jul 13, 2026, 11:54 PM UTC

   This issue is resolved. Please follow https://status.arista.io/incidents/5vx7cvb07k7d for postmortem update when it becomes available.

Read the full incident report →

Started May 29, 2026, 08:24 PM UTC· resolved Jun 04, 2026, 12:50 AM UTC

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

2. investigating May 29, 2026, 08:25 PM UTC

   We are continuing to investigate this issue.

3. investigating May 29, 2026, 09:02 PM UTC

   We are continuing to investigate this issue.

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

5. investigating May 29, 2026, 11:01 PM UTC

   We are continuing to investigate this issue.

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

7. identified May 30, 2026, 10:57 AM UTC

   We are testing the fixes in the staging environment.

8. identified May 30, 2026, 05:35 PM UTC

   We are applying fixes and are selectively enabling Network Provisioning.

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

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

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

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

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

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

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

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

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

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

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

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

21. resolved Jun 04, 2026, 12:50 AM UTC

    This incident has been resolved.

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

Read the full incident report →

Started May 29, 2026, 05:45 PM UTC· resolved May 29, 2026, 09:02 PM UTC

1. identified May 29, 2026, 05:45 PM UTC

   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.

2. identified May 29, 2026, 06:49 PM UTC

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

3. monitoring May 29, 2026, 07:13 PM UTC

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

4. monitoring May 29, 2026, 09:02 PM UTC

   We are continuing to monitor for any further issues.

5. resolved May 29, 2026, 09:02 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 26, 2026, 03:38 PM UTC· resolved May 27, 2026, 01:02 AM UTC

1. investigating May 26, 2026, 03:38 PM UTC

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

2. monitoring May 26, 2026, 04:35 PM UTC

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

3. resolved May 27, 2026, 01:02 AM UTC

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

Read the full incident report →

Started May 15, 2026, 05:24 PM UTC· resolved May 15, 2026, 05:30 PM UTC

1. investigating May 15, 2026, 05:24 PM UTC

   tags API is affected. We are currently investigating this issue.

2. resolved May 15, 2026, 05:30 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 12, 2026, 03:33 PM UTC· resolved Mar 12, 2026, 09:57 PM UTC

1. identified Mar 12, 2026, 03:33 PM UTC

   We are investigating a performance degradation when when loading the Tasks windows within Provisioning. For customers with a large number of historical tasks, page load times have increased significantly. This will significantly impact core provisioning workflows. We are aware of the underlying cause and are actively working on a fix.

2. monitoring Mar 12, 2026, 09:36 PM UTC

   A fix is currently being deployed.

3. resolved Mar 12, 2026, 09:57 PM UTC

   The fix has been successfully deployed to all regions. Customers will have to reload the UI for the changes to take effect.

Read the full incident report →

Started Mar 04, 2026, 05:23 AM UTC· resolved Mar 04, 2026, 06:43 AM UTC

1. investigating Mar 04, 2026, 05:23 AM UTC

   We are currently investigating a partial outage of Secured ZTP (sztp) / License management functionality.

2. resolved Mar 04, 2026, 06:43 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 03, 2026, 04:15 AM UTC· resolved Mar 03, 2026, 04:31 AM UTC

1. investigating Mar 03, 2026, 04:15 AM UTC

   We are currently investigating this issue.

2. monitoring Mar 03, 2026, 04:24 AM UTC

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

3. resolved Mar 03, 2026, 04:31 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 13, 2026, 01:30 AM UTC· resolved Feb 17, 2026, 04:54 PM UTC

1. investigating Feb 13, 2026, 01:30 AM UTC

   We are investigating an issue with the Change Control page where configuration diffs are failing to load. We are working to identify the root cause.

2. identified Feb 13, 2026, 01:47 AM UTC

   We have identified the cause of the loading issues on the Change Control page and are currently evaluating the full extent of the impact.

3. identified Feb 13, 2026, 02:42 AM UTC

   We have narrowed the scope of this issue. Impact is limited to customers with the "Studios - Partial Configuration Management (Beta)" feature enabled. Our team is currently determining the next steps for a fix.

4. monitoring Feb 13, 2026, 11:32 PM UTC

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

5. resolved Feb 17, 2026, 04:54 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 30, 2026, 02:36 PM UTC· resolved Jan 30, 2026, 04:05 PM UTC

1. investigating Jan 30, 2026, 02:36 PM UTC

   We are aware of an issue with our email system, and the 'Log in with Email' is currently unavailabe. We have identified the cause and are working on a mitigation.

2. resolved Jan 30, 2026, 04:05 PM UTC

   Login by email is functional again. We apologize for this disruption and will be following up with a postmortem.

3. postmortem Feb 05, 2026, 10:02 PM UTC

   **Incident Report: Login By Email Service Outage - January 30th, 2026** On January 30, 2026, CloudVision as-a-Service experienced a service outage affecting the "Login By Email" functionality lasting 2 hours and 36 minutes. During this window, customers attempting to access their accounts using Login By Email failed to receive the invitation emails. This incident was isolated strictly to the Login By Email service; SSO and SAML based login remained fully operational. There was no data loss or compromise of customer information. This outage was not the result of a security breach, unauthorized intrusion, or any malicious activity. **Root Cause** Our investigation identified a gap in monitoring for a critical third-party integration. Because this specific telemetry was missing, early warning signals were missed, leading to the eventual service disruption. Additionally, we identified internal process failures that contributed to the duration of the outage. **Our Response** Internal escalation protocols successfully engaged subject matter experts within 30 minutes of the first reported case. Initial delays in resolution were primarily due to various process failures including delays in required coordination with third party vendor. We are implementing the missing monitoring triggers for third-party integrations to ensure early detection, as well as reviewing our processes as part of various fixes we are addressing. We understand that any service disruption is impactful. We are committed to implementing changes identified during our internal investigation to prevent this type of failure from happening again. Thank you for using CloudVision as-a-Service.

Read the full incident report →

Started Jan 23, 2026, 09:28 AM UTC· resolved Jan 23, 2026, 12:13 PM UTC

1. investigating Jan 23, 2026, 09:28 AM UTC

   We are investigating a platform degradation in the US region.

2. investigating Jan 23, 2026, 09:46 AM UTC

   We are continuing to investigate this issue.

3. monitoring Jan 23, 2026, 11:01 AM UTC

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

4. resolved Jan 23, 2026, 12:13 PM UTC

   Telemetry was delayed for up to 30 minutes due to an disruptive infrastructure reconfiguration. The incident has now been resolved.

Read the full incident report →

Started Jan 15, 2026, 08:53 PM UTC· resolved Jan 15, 2026, 11:49 PM UTC

1. identified Jan 15, 2026, 08:53 PM UTC

   We experienced a temporary service disruption due to underlying disruption with our cloud provider. We are recovered, but currently investigating the full extent of the impact and monitoring the situation.

2. monitoring Jan 15, 2026, 09:08 PM UTC

   The issue with our underlying layer has been resolved but we are monitoring this service region.

3. resolved Jan 15, 2026, 11:49 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 12, 2026, 09:48 PM UTC· resolved Jan 13, 2026, 12:11 AM UTC

1. monitoring Jan 12, 2026, 09:48 PM UTC

   Hello CloudVision as a Service users, We experienced an unexpected surge of "Device Stopped Streaming" events to fire between 2026-01-12 19:24:40 UTC and 2026-01-12 19:29:43. This was due to unexpected result of a change being applied causing a behavior that we did not anticipate. We apologize for the noise caused and are investigating how to prevent similar class of outcome in the future. Thank you for your patience.

2. resolved Jan 13, 2026, 12:11 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 19, 2025, 05:22 PM UTC· resolved Dec 19, 2025, 10:17 PM UTC

1. monitoring Dec 19, 2025, 05:22 PM UTC

   Because of Cloudflare incident ( https://www.cloudflarestatus.com/incidents/dz87vqwvl8wr ) clients may experience intermittent network problems. We are not detecting availability problems at the moment, but monitoring the situation.

2. resolved Dec 19, 2025, 10:17 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Dec 09, 2025, 05:42 PM UTC· resolved Dec 09, 2025, 11:59 PM UTC

1. monitoring Dec 09, 2025, 05:42 PM UTC

   We are aware of an issue where device streaming latency spiked around December 9th, 12:55 UTC that lasted about ~10minutes. This is not an ongoing issue. This is courtesy notice as we continue to triage this incident. Thank you for being valued users of CloudVision as a Service.

2. resolved Dec 09, 2025, 11:59 PM UTC

   Closing this courtesy notice.

Read the full incident report →

Started Dec 08, 2025, 11:57 PM UTC· resolved Dec 08, 2025, 11:57 PM UTC

1. resolved Dec 08, 2025, 11:57 PM UTC

   Hello CloudVision as a Service customers, We have identified an issue impacting a small subset of customers where all EOS devices in a tenant were incorrectly marked as inactive. Importantly, the devices were actively streaming and all data and telemetry were generated and stored correctly. Impacted customers may have observed this incorrect streaming status displayed for several consecutive hours or days since November 25th, 2025. We have identified the root cause and deployed an immediate fix. There is no action required from you as the customer. This is a courtesy notice only. If you have any questions about this issue or if your tenant was affected, please reach out to [email protected]. Thank you for being a valued CloudVision as a Service customer.

Read the full incident report →