Auvik Status

# Service Disruption - SNMPv3 Monitoring Loss Following Collector Upgrade ## Root Cause Analysis ### Duration of the incident Discovered: Apr 13, 2026 20:00 - UTC Resolved: Apr 13, 2026 22:32 - UTC ### Customer impact Customers experienced a loss of monitoring data from only devices using specific SNMPv3 configurations. While devices remained online and reachable, monitoring data was not collected, resulting in reduced visibility across environments. ### Cause A recent collector upgrade introduced changes to encryption handling that affected support for certain legacy SNMPv3 configurations. This resulted in failures when attempting to collect data from devices configured that way. ### Effect Monitoring data collection failed for affected devices across multiple clusters. This led to a noticeable drop in available device metrics and visibility, despite no loss of connectivity to the devices themselves. ### Future consideation\(s\) * Expand test coverage to include a broader range of SNMP configurations * Improve monitoring to detect drops in data collection more proactively * Strengthen validation processes for major upgrades and dependency changes * Implement additional safeguards to identify compatibility issues prior to release

# Service Degraded - Some Customers Experiencing Login Issues After Maintenance ## Root Cause Analysis ### Duration of the incident Discovered: Mar 7, 2026 18:42 - UTC Resolved: Mar 9, 2026 21:10 - UTC ### Cause Following a platform upgrade, an internal reconciliation process incorrectly identified a subset of user records as deleted. This occurred due to an error condition in a synchronization component that failed to process all expected user data during reconciliation. ### Effect Affected users were able to log in to the platform but were unable to access their expected sites or tenants due to missing user authorizations. In some cases, API access using previously generated API keys was also affected. Monitoring, alerting, and data collection services continued to function normally throughout the incident. ### Action taken Engineering paused the process that spreads the changes across the platform to prevent further impact. User access was then restored using backup data taken prior to the upgrade. This allowed the team to recover user access, permissions, and related access keys. After restoration was completed and access was verified across all environments, the incident was declared resolved. ### Future consideration\(s\) * Implement additional monitoring to detect unexpected changes in user or authorization records. * Add safeguards within reconciliation processes to prevent large-scale unintended deletions. * Improve post-upgrade validation checks to identify abnormal record changes earlier. * Enhance disaster recovery tooling and backup retrieval processes to speed up restoration efforts.

# Service Disruption - The EU2 cluster was unavailable ## Root Cause Analysis ### Duration of the incident Discovered: Dec 15, 2025 20:00 – UTC Resolved: Dec 16, 2025 02:00 – UTC ### Customer impact During the incident window, customers hosted in the EU2 region experienced intermittent service degradation. This included slower system responsiveness, temporary inconsistencies in monitoring data, and brief periods where alerts may have been delayed or inaccurate. Most customers regained access as services were progressively restored, and complete stability was confirmed before the incident was closed. ### Cause The incident was caused by an elevated load in the EU2 service environment, resulting in an uneven workload distribution across backend resources. As the load increased, automated recovery mechanisms were unable to stabilize the environment fully, necessitating a controlled restart of the regional service to restore normal operations. ### Effect The imbalance led to reduced service performance and temporary unavailability for some customers until recovery actions were completed. Engineering teams were required to intervene to safely restart the affected region and validate service health before returning operations to normal. ### Future consideation\(s\) * Improve automated workload balancing to absorb regional load increases. * Strengthen early indicators for backend saturation to enable earlier intervention. * Refine operational procedures to further reduce recovery time in similar scenarios.

# Service Degraded - Duplicated Devices for Meraki Switch Stacks ## Root Cause Analysis ### Duration of the incident Discovered: Dec 15, 2025 08:34 – UTC Resolved: Dec 15, 2025 13:20 – UTC ### Customer impact Customers with Meraki switch stacks across all clusters experienced: Duplicate Meraki switches are appearing in the device inventory, including entries without management IP addresses. Inability to manually delete duplicates, as they were automatically recreated. Confusing or inaccurate device and stack representations. Temporary inflation of billable device counts for some tenants \(billing data captured and under review\). No other device types were affected. ### Cause A configuration update intended to improve how Meraki switch stacks are represented in the platform caused unintended behavior. For tenants already using Meraki stacking, the system was unable to match newly processed stack data to existing switches consistently. This caused already-stacked switches to be incorrectly interpreted as new devices, generating duplicate inventory entries. Because the underlying synchronization logic reinforced these entries, any customer deletion of duplicates did not persist, and duplicates reappeared. ### Effect The issue led to inaccurate device inventories and misleading switch-stack views for customers using Meraki stacking, causing confusion in device management and increasing support tickets. Internal teams experienced additional operational overhead as they investigated the duplication patterns and validated safe removal procedures. Complete remediation required coordinated cleanup across all clusters to restore accurate device records and ensure no further duplicates were generated. ### Future consideration\(s\) * Strengthen validation of device and stack metadata before inventory updates. * Improve testing coverage using a production-like stacked device configuration. * Add monitoring and alerting for abnormal changes in device counts. * Use safer rollout controls and feature flags for changes affecting device inventory logic.

# Service Degraded - FortiGate firewalls duplicated in the EU2 cluster, causing a flood of alerts. ## Root Cause Analysis ### Duration of the incident Discovered: Dec 11, 2025 14:00 – UTC Resolved: Dec 17, 2025 06:45 – UTC ### Customer impact Clients with FortiGate firewalls in the EU2 region experienced: * A significant increase in “device offline” alerts due to status flapping between duplicate and original device entries. * Duplicate firewalls appear in inventory views, leading to confusion in device management. * Inaccurate device statistics and monitoring gaps. * In some cases, customers attempted to delete duplicates, which resulted in the loss of historical data on the original device. No other device types or regions were affected. ### Cause A system change intended to improve how high-availability firewall configurations were processed introduced unexpected behavior. Under certain conditions, the platform was unable to detect when multiple records referenced the same firewall device consistently. As a result, some firewalls were incorrectly detected as new devices, causing duplicate entries and inconsistent operational status reporting. ### Effect The issue resulted in elevated alert volumes across impacted tenants and caused instability in device-status reporting for the affected firewalls. Customers experienced increased operational overhead as they reviewed unexpected alerts and duplicate device entries, and engineering teams were required to intervene to restore accurate device associations and remove the duplicated records.fFuture consideration\(s\) * Strengthen validation of device-supplied information before it affects inventory or monitoring. * Implement alerting for sudden spikes in offline/online transitions to detect similar issues earlier. * Improve observability of device lifecycle behavior to identify anomalies proactively. * Use feature-flagged or staged rollouts for changes that affect device processing logic. * Incorporate production-like data into pre-deployment testing to better anticipate unexpected device behaviors.

The incident has been fully resolved, and all services are operating normally. Customers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support. We appreciate your understanding and patience.

Latest update from Okta Incident Resolved December 3, 2025 at 8:58am PST An issue impacting the core authentication service for customers in Okta Cell US7 has been resolved. Additional root cause information will be available within five business days. We will close the status page for Auvik's sites.

# Service Degraded - Data Not Loading Across All Clusters ## Root Cause Analysis ### Duration of the incident Discovered: Nov 21, 2025 17:43 – UTC Resolved: Nov 21, 2025 19:18 – UTC ### Customer impact Customers across all regions were able to log in, but many were unable to view key data within the platform. This included features such as: * Network maps * Inventory and site lists * Dashboards * Other views are dependent on permissions and hierarchical data. This resulted in degraded usability and limited visibility into managed environments. ### Cause During a routine maintenance task intended to clean up older data records, an incorrect piece of information was unintentionally added to the system. This faulty data prevented a core component—responsible for organizing how customer information is displayed in the platform—from functioning correctly. Because this component could not run as expected, many areas of the product that rely on structured data \(such as maps, dashboards, and inventory views\) were unable to load. This led to widespread service degradation across all clusters. ### Effect Because the system could not correctly load the information needed to display customer environments, several parts of the platform were unable to show data. As a result, many users could log in but were unable to see maps, inventory details, site lists, dashboards, or other information they usually rely on. This created a degraded experience across all regions, limiting visibility and making it difficult for customers to perform routine monitoring and management tasks until the issue was resolved. ### Future consideation\(s\) * Introduce stronger validation and safeguards to prevent malformed data from being accepted into critical systems. * Improve the resilience of backend services so they fail gracefully rather than entering repeated restart cycles. * Implement additional monitoring to provide earlier detection of issues affecting data-loading functions. * Enhance internal tools used during maintenance and cleanup activities to reduce the risk of unintentional data corruption.

The incident has been fully resolved, and all services are operating normally. Customers should no longer experience any related issues. If you continue to experience problems, please don't hesitate to contact Auvik Support.

# Service Degraded - Sites have lost settings after maintenance ## Root Cause Analysis ### Duration of the incident Discovered: Oct 11, 2025 – 12:00 UTC Resolved: Oct 15, 2025 – 22:00 UTC ### Cause During a scheduled system update, a background maintenance process unintentionally removed reference files used to identify stored site configurations. When affected systems restarted after the update, they were unable to locate those configuration files and temporarily appeared as new, empty sites. This occurred because the maintenance process was using outdated information when determining which data to clean up safely. The underlying data remained securely stored, but the missing reference files prevented normal access until they were restored. ### Effect A subset of tenants across multiple clusters temporarily lost access to their site configurations and appeared as newly created environments. Customers observed missing data and configurations, including previously defined network settings and device details. ### Action taken _All times are in UTC_ **10/11/2025** **12:00** – A scheduled system upgrade began across all clusters. **15:25** – The support team received reports from customers that some sites appeared empty or missing data. **16:00** – Engineering immediately began investigating and determined this was not related to normal data processing delays. **10/12/2025** Additional reports confirmed that several sites were missing configuration information. The engineering team confirmed that the original data was still securely stored, but was not being correctly loaded by the system. **10/13/2025** The issue was traced to missing metadata files that help identify stored configurations. The engineering team began restoring affected sites using the most recent valid configuration data. Automated recovery tools were developed to safely restore additional sites and ensure consistent recovery across all clusters. **10/14/2025** Engineering verified that configuration data was fully restored and synchronized across supporting services. The recovery process was extended to all remaining sites, with validation steps confirming successful restoration. **10/15/2025** Final recovery efforts for the remaining affected clusters were completed.. **22:00** – All affected sites were confirmed operational with their configurations restored and verified. ### Future consideration\(s\) * Remove dependency of cleanup processes on outdated cluster data sources. * Validate all automated cleanup jobs to ensure they do not operate on production clusters. * Implement monitoring for missing or corrupted metadata files before deployments. * Enhance post-deployment validation to verify the integrity of configuration data across all clusters.

The emergency maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.

The scheduled maintenance has been completed.