Auvik Networks Inc. Status Page

Apr 14, 2026 · resolved Apr 14

# 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

Mar 8, 2026 · resolved Mar 9

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

Dec 15, 2025 · resolved Dec 16

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

Dec 15, 2025 · resolved Dec 15

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

Dec 11, 2025 · resolved Dec 11

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