CVaaS Status

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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

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

Resolved: This incident has been resolved.

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

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

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

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

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

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

Monitoring: Network Provisioning services have been fully restored across all CVaaS service regions. Customers requiring additional assistance have been contacted directly by our team. For all other users, Network Provisioning features are now available for normal operation.

Identified: We are continuing to restore Network Provisioning operation for select clusters.

We will provide another update no later than May 31st, 11:00pm UTC.

Identified: 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: 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: 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: We have restored Network Provisioning operation for select clusters.

We will provide another update no later than May 30th, 11:00pm UTC.

Identified: We are applying fixes and are selectively enabling Network Provisioning.

Identified: We are testing the fixes in the staging environment.

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

Investigating: We are continuing to investigate this issue.

Investigating: 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: We are continuing to investigate this issue.

Investigating: We are continuing to investigate this issue.

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