auvik-network-alerts

name	auvik-network-alerts
description	Surface and triage Auvik network alerts by severity, status, dismissed state, or time window across MSP tenants. Use when reviewing active alerts, investigating a specific device's alert history, filtering by severity (emergency/critical/warning), checking whether alerts are resolved or still open, or pulling alerts within a date range for incident review.
license	Apache-2.0
metadata	{"openclaw":{"requires":{"bins":"[Truncated]","env":"[Truncated]"}}}

Auvik Network Alerts

Surface, filter, and triage alerts generated by the Auvik network monitoring platform. Scope by severity, status, entity (device), tenant, or time window. All operations are read-only — alert dismissal must be performed in the Auvik Dashboard.

MCP Server

• Server: auvik-mcp (NetClaw MCP, Feature 036)
• Command: python3 mcp-servers/auvik-mcp/auvik_mcp_server.py (stdio transport)
• Auth: Basic auth via AUVIK_USERNAME + AUVIK_API_KEY
• Read-only: GET operations only — alert state cannot be modified through this skill

Available Tools

Tool	What It Does
auvik_list_alerts	List alert history; filter by severity, status, dismissed state, entity, time window, or alert definition; resolves device name/IP to Auvik entity ID

Key Concepts

Tenants = MSP clients. Each managed customer is a separate Auvik tenant. Provide tenants=<name-or-domain-prefix> to scope alerts to a single client. Omit to query across all visible tenants.

Identifier resolution. The entity parameter accepts a device name, hostname, or IP address — the server resolves it to the Auvik internal entity ID. If the name matches multiple devices, the tool returns ResolutionCandidate[] so you can narrow the query.

Severity levels. Auvik alerts use five severities in descending urgency: emergency, critical, warning, info, unknown. Filter with the severity parameter.

Status values. An alert may be created (open/active), resolved, paused, or unpaused. Use status=created to see only open alerts.

Dismissed vs. active. Dismissed alerts are hidden in the Dashboard but remain in history. Use dismissed=false to exclude them (recommended for triage); dismissed=true to review what was dismissed and when.

Time windows. detected_time_after and detected_time_before accept ISO-8601 datetime strings (e.g., 2026-06-01T00:00:00Z). Use both to bound a review window for incident post-mortems.

Cursor pagination. auvik_list_alerts auto-aggregates all pages up to AUVIK_MAX_PAGES. Use fetch_all=false for incremental loading on large alert queues.

Workflow

Morning Alert Triage

1. Start GAIT branch: gait_branch with name like auvik-alert-triage-2026-06-21
2. List open alerts: auvik_list_alerts with status=created, dismissed=false
3. Filter critical/emergency: add severity=critical or severity=emergency for priority triage
4. Scope to tenant: add tenants=<client> to focus on a specific managed client
5. Check device context: use auvik-inventory (auvik_list_devices) to get device details for the alerting entity
6. Record in GAIT: commit alert summary with count, top severities, and any affected devices

Investigate Alerts for a Specific Device

1. Resolve device name: auvik_list_alerts with entity=<device-name-or-IP> — the resolver identifies the entity
2. Review full history: omit status filter to see both open and resolved alerts
3. Check time pattern: pass detected_time_after=<start> + detected_time_before=<end> to narrow to a maintenance window or incident period
4. Cross-reference lifecycle: use auvik-lifecycle (auvik_list_device_lifecycle) to check if the device is EoL — recurring alerts on EoL hardware signal replacement need
5. Record in GAIT: commit alert history and investigation findings

Incident Post-Mortem Alert Pull

1. Define incident window: note start/end times in ISO-8601
2. Pull all alerts in window: auvik_list_alerts with detected_time_after=<start>, detected_time_before=<end>, tenants=<client>
3. Review dismissed: re-run with dismissed=true to see if any alerts were silenced during the incident
4. Correlate with change records: compare alert timestamps with servicenow-change-workflow change records
5. Record in GAIT: commit post-mortem findings with alert timeline

Integration with Other Skills

Skill	How They Work Together
gait-session-tracking	Mandatory — start a branch before querying, record every turn, close with gait_log
auvik-inventory	Get device details and entity context for alerting assets
auvik-lifecycle	Correlate recurring alerts with EoL/warranty status — recurring alerts on end-of-life hardware signal refresh urgency
auvik-performance	After identifying alerting devices, pull performance stats to understand the conditions that triggered alerts
servicenow-change-workflow	Correlate alert timestamps with approved change records to confirm or rule out change-induced incidents

Environment Variables

Variable	Required	Description
AUVIK_USERNAME	Yes	Auvik user email (Basic-auth username)
AUVIK_API_KEY	Yes	Auvik API key (Basic-auth password)
AUVIK_BASE_URL	No	Regional cluster URL; defaults to https://auvikapi.us1.my.auvik.com — swap us1 for your region
AUVIK_VERIFY_SSL	No	Set false to skip TLS verification (not recommended)
AUVIK_TIMEOUT	No	HTTP timeout in seconds (default: 30)
AUVIK_MAX_PAGES	No	Pagination safety cap (default: 50)

Important Rules

• Read-only — this skill cannot dismiss, acknowledge, or modify alert state. Alert management must be done in the Auvik Dashboard.
• Refer to devices by name or IP, not by Auvik entity IDs. Pass entity=<hostname-or-IP> and let the resolver do the lookup.
• Scope to a tenant in MSP environments to avoid mixing alerts across clients.
• Do not conflate dismissed with resolved — a dismissed alert may still indicate an unresolved condition; resolved means Auvik determined the condition cleared.
• Record every session in GAIT — triage sessions, post-mortem pulls, and investigation findings all go to the audit trail.