AI agent skill · by @automateyournetwork

Auvik Network Alerts

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.

Archived 2026-10-23 · Source updated 2026-10-11 · License: Apache-2.0. Check the original repository for the latest version.

SKILL.md instructions

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

## Failure Behavior

- If a tool call fails with an authentication or connection error, check that `AUVIK_API_KEY`, `AUVIK_BASE_URL`, `AUVIK_USERNAME` are set and valid before assuming a data or device problem.
- On a tool error (timeout, unreachable host, malformed response), report the failure and its error message directly to the user rather than fabricating or guessing at results.
- For a confirmed read-only call, check connectivity and retry once if appropriate. For any call that changes state or sends a message, a timeout does not prove the action failed: inspect current state or delivery status before retrying, preserve the required approval/change gates, and do not repeat an action whose outcome is unknown.