alert-triage

/alert-triage

If you see unfamiliar placeholders, see CONNECTORS.md.

Pull and correlate active alerts across all CP monitoring systems into a unified triage view.

Usage

/alert-triage $ARGUMENTS

Examples:

• /alert-triage all — all systems, all severities
• /alert-triage critical — critical alerts only, all systems
• /alert-triage ninjaone — NinjaOne RMM alerts only
• /alert-triage azure high — Azure alerts at High severity

Steps

1. Query each requested system for active/open alerts
2. Deduplicate: same device/resource alerting across multiple systems = one entry
3. Correlate: group alerts that share a probable root cause (e.g., switch down → AP alerts)
4. Prioritize by severity: Critical → High → Medium → Low
5. For each critical/high alert: assess likely cause and recommend immediate action
6. Flag potential cascading failures
7. Output unified triage report

Alert Source Systems

System	What It Monitors	Connector
NinjaOne	Endpoints (Windows/Mac), servers, patch state, disk/CPU/RAM	~~rmm
Meraki	Network — switches, APs, MX appliances, WAN uplinks	~~network
Azure Monitor	Cloud resources — VMs, App Services, databases, function apps	~~cloud

Severity Mapping

NinjaOne	Meraki	Azure	Unified Severity
Critical	—	Critical (Sev 0/1)	🔴 Critical
Major	Alert (uplink down)	Error (Sev 2)	🟠 High
Minor	Warning	Warning (Sev 3)	🟡 Medium
Informational	Info	Informational	⚪ Low

Correlation Patterns

Pattern	Probable Cause
MX alert + multiple AP alerts (same venue)	WAN or upstream switch failure
Multiple Windows endpoints: high CPU	Malware scan, patch deployment, or event
NinjaOne disk alert + Azure backup failure	Disk full blocking backup job
Azure VM unreachable + NinjaOne agent offline	VM crashed or network partition
Multiple devices: auth failure alerts	Entra ID outage or DC issue

Output

## Alert Triage — [timestamp]

**Systems queried:** [NinjaOne / Meraki / Azure / All]
**Total active alerts:** [N]
**Critical:** [N] | High: [N] | Medium: [N] | Low: [N]

---

### 🔴 Critical Alerts

#### [Alert Title / Device Name]
- **Source:** [NinjaOne / Meraki / Azure]
- **Alert:** [description]
- **Resource:** [device / resource name]
- **Since:** [time — X hours ago]
- **Probable cause:** [assessment]
- **Immediate action:** [specific step]
- **Related alerts:** [list if correlated]
- **Jira ticket:** [create one / already exists: [ticket ID]]

---

### 🟠 High Alerts

[same format, abbreviated]

---

### 🟡 Medium Alerts (summary)
| Alert | Source | Device | Since |
|-------|--------|--------|-------|
| [alert] | [source] | [device] | [time] |

---

### Correlation Groups
- **Group 1 — Venue network issue (Pier 60):** MX uplink down → 3 AP alerts → 2 NinjaOne agent offline alerts. Single root cause: WAN failure. Action: check `/sd-wan-status Pier 60`.
- **Group 2 — [description]**

### Alert Storm Assessment
[If >10 alerts: assess if this is an alert storm vs. a genuine outage. Recommend muting low-severity alerts during incident response.]

### Recommended Next Steps
1. [Priority 1 action]
2. [Priority 2 action]
3. Run `/incident-postmortem` when resolved if any Critical alert lasted >30 minutes

If Connectors Available

If ~~rmm (NinjaOne) is connected:

• Query ninjaone_list_alerts for open alerts, filter by severity
• Pull device context for each alert via ninjaone_get_device

If ~~network (Meraki) is connected:

• Query meraki_get_network_alerts for each venue network
• Cross-reference with meraki_get_uplink_status for WAN alerts

If ~~cloud (Azure) is connected:

• Query Azure Monitor alerts API for fired alerts in last 24h
• Pull resource health for VMs and App Services

If no connectors:

• Output checklist: NinjaOne dashboard URL, Meraki dashboard URL, Azure Monitor alerts URL
• Provide manual severity classification table

CP-Specific Notes

• Morning ops: IT team should run /alert-triage all each morning before 9am. Any Critical = create Jira incident ticket immediately.
• On-call escalation: Critical alerts after hours escalate to the on-call SysAdmin via [CP paging method]. Do not let Critical alerts sit >15 minutes unacknowledged.
• Alert fatigue: if Medium or Low alerts consistently fire without action, they should be reviewed for threshold adjustment — not suppressed. Flag patterns to IT Manager monthly.
• Meraki alerting: Meraki alerts are also sent to [CP alert email]. Check that alerting is still enabled via Meraki Dashboard → Network-wide → Alert settings.
• Cerberus escalation: for ambiguous alerts (unknown cause, cross-system pattern), invoke Cerberus council via cerberus_council for a multi-perspective assessment before deciding on action.
• SLA clock: any alert that becomes a user-impacting incident starts the SLA clock. Reference /sla-check to monitor open ticket SLA status.