# Datto RMM Alerts

> Datto RMM alert structure, priorities, and the 25+ alert context types (antivirus_ctx, eventlog_ctx, perf_disk_usage_ctx, ransomware_ctx, and more), each with its own type-specific fields. Covers alert resolution workflows and context-specific triage guidance.

- Skill: `wyre-ai/datto-rmm-alerts` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add wyre-ai/datto-rmm-alerts`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wyre-ai/datto-rmm-alerts/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: WYRE-AI (https://skillmd.com/u/wyre-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wyre-ai/datto-rmm-alerts

---


# Datto RMM Alert Management

## Overview

Alerts are the primary notification mechanism in Datto RMM. They're generated by monitors when conditions are met - disk space low, service stopped, CPU high, etc. Each alert contains context-specific data based on the monitor type. This skill covers alert handling, the 25+ context types, and resolution workflows.

## Anti-triggers

- **A SOC-confirmed threat rather than a monitor firing** —
  `ransomware_ctx` and `antivirus_ctx` alerts are monitor output, not
  analyst verdicts; use `rocketcyber-incidents`.
- **Backup failures** — appliance and SaaS backup raise alerts on their
  own surfaces; use `datto-bcdr-api-patterns` or
  `unitrends-api-patterns`.
- **VSA alarms** — Kaseya's other RMM raises its own alarm objects; use
  `kaseya-vsa-api-patterns`.
- **An alert raised by a different RMM** — every RMM here emits objects
  called alerts with their own severity words; only the enrolled agent
  disambiguates. Use `atera-alerts`, `ninjaone-alerts`,
  `superops-alerts`, or `connectwise-automate-alerts`.
- **A signal that pages a human** — incident platforms also call their
  inbound events alerts, but those route to a responder rather than
  resolving on the device; use `pagerduty-alerts` or `rootly-alerts`.

## Key Concepts

### Alert Structure

Every alert has:
- **alertUid** - Unique identifier for the alert
- **alertType** - Category of alert (Device Offline, Monitor, etc.)
- **priority** - Severity level (Critical, High, Moderate, Low, Information)
- **alertContext** - Type-specific data with `@class` discriminator
- **timestamp** - When the alert was raised (Unix milliseconds)

### Alert Priorities

| Priority | Value | Description | Typical Response |
|----------|-------|-------------|------------------|
| Critical | `Critical` | Severe impact, immediate action | 15 minutes |
| High | `High` | Significant issue | 1 hour |
| Moderate | `Moderate` | Notable but manageable | 4 hours |
| Low | `Low` | Minor issue | 8 hours |
| Information | `Information` | Informational only | Best effort |

### Alert States

| State | Description |
|-------|-------------|
| `open` | Active, requires attention |
| `resolved` | Closed, issue addressed |

## Field Reference

### Alert Object

```typescript
interface Alert {
  // Identifiers
  alertUid: string;              // Unique alert ID
  alertSourceInfo: AlertSource;  // Source of the alert

  // Device Info
  deviceUid: string;             // Device that generated alert
  hostname: string;              // Device hostname

  // Classification
  alertType: string;             // "Monitor", "Device Offline", etc.
  priority: AlertPriority;       // Critical, High, Moderate, Low, Information
  alertMessage: string;          // Human-readable message

  // Context (varies by @class)
  alertContext: AlertContext;    // Type-specific data

  // Timestamps (Unix milliseconds)
  timestamp: number;             // When alert was raised
  resolvedAt?: number;           // When resolved (if resolved)

  // Resolution
  resolved: boolean;
  resolvedBy?: string;           // Who resolved it
  resolution?: string;           // Resolution notes
}

type AlertPriority = 'Critical' | 'High' | 'Moderate' | 'Low' | 'Information';
```

## Alert Context Types

Datto RMM has 25+ alert context types, identified by the `@class` field in `alertContext`. Each type carries fields specific to that monitor.

| `@class` | Monitor | Key Fields |
|----------|---------|------------|
| `antivirus_ctx` | Antivirus status/detection | avProduct, avStatus, threatName, threatPath |
| `comp_script_ctx` | Component script execution | componentName, exitCode, stdout, stderr |
| `custom_snmp_ctx` | SNMP monitoring | oid, value, threshold, comparison |
| `disk_health_ctx` | ESXi disk health | diskName, status, smartStatus, temperature |
| `eventlog_ctx` | Windows Event Log | logName, source, eventId, eventType, message |
| `fan_ctx` | ESXi fan status | fanName, status, rpm |
| `fs_object_ctx` | File/folder size | path, size, threshold, isDirectory |
| `online_offline_status_ctx` | Device online/offline | status, lastSeen, offlineDuration |
| `patch_ctx` | Windows patch status | patchCount, criticalCount, rebootRequired |
| `perf_disk_usage_ctx` | Disk usage/space | drive, usagePercent, freeSpace, usedSpace |
| `perf_mon_ctx` | Windows Performance Counter | counter, instance, value, threshold |
| `perf_resource_usage_ctx` | CPU/Memory usage | resource, usagePercent, duration, processName |
| `ping_ctx` | Network ping | host, latency, packetLoss, status |
| `process_resource_usage_ctx` | Process resource usage | processName, pid, cpuUsage, memoryUsage |
| `process_status_ctx` | Process running/stopped | processName, status, expectedStatus |
| `psu_ctx` | ESXi power supply | psuName, status, wattage |
| `ransomware_ctx` | Ransomware detection | detectionType, path, action, fileCount |
| `sec_management_ctx` | Webroot/security management | product, status, threatCount, licenseExpiry |
| `srvc_resource_usage_ctx` | Windows Service resource usage | serviceName, cpuUsage, memoryUsage |
| `srvc_status_ctx` | Windows Service status | serviceName, status, expectedStatus, startType |
| `sw_action_ctx` | Software install/remove | action, softwareName, version, publisher |
| `temperature_ctx` | ESXi temperature | sensorName, temperature, threshold, status |
| `wmi_ctx` | WMI query monitoring | query, namespace, property, value |

See [references/alert-contexts.md](references/alert-contexts.md) for the complete field definitions and example alerts for each context type.

## API Patterns

### Get All Open Alerts

```http
GET /api/v2/alerts/open
Authorization: Bearer {token}
```

### Get Open Alerts for Site

```http
GET /api/v2/site/{siteUid}/alerts/open
Authorization: Bearer {token}
```

### Get Open Alerts for Device

```http
GET /api/v2/device/{deviceUid}/alerts/open
Authorization: Bearer {token}
```

### Get Resolved Alerts

```http
GET /api/v2/alerts/resolved?max=250
Authorization: Bearer {token}
```

### Get Alerts Since Timestamp

```http
GET /api/v2/alerts/open?since=1707991200000
Authorization: Bearer {token}
```

### Resolve an Alert

```http
POST /api/v2/alert/{alertUid}/resolve
Authorization: Bearer {token}
Content-Type: application/json

{
  "resolution": "Cleared disk space by removing temp files"
}
```

**Note:** Muting alerts (PUT to /alert/{alertUid}/mute) is deprecated. Use resolve instead.

## Workflows

### Alert Triage by Priority

```javascript
async function triageAlerts(client) {
  const alerts = await client.request('/api/v2/alerts/open');

  const triaged = {
    critical: [],
    high: [],
    moderate: [],
    low: [],
    information: []
  };

  alerts.alerts.forEach(alert => {
    const bucket = alert.priority.toLowerCase();
    if (triaged[bucket]) {
      triaged[bucket].push(alert);
    }
  });

  return triaged;
}
```

### Context-Aware Alert Handling

```javascript
function getAlertRecommendation(alert) {
  const ctx = alert.alertContext;

  switch (ctx['@class']) {
    case 'perf_disk_usage_ctx':
      return {
        severity: ctx.usagePercent >= 95 ? 'critical' : 'warning',
        action: 'Clear disk space or expand volume',
        steps: [
          'Run Disk Cleanup utility',
          'Clear temp files',
          'Check for large log files',
          'Consider expanding disk'
        ]
      };

    case 'srvc_status_ctx':
      return {
        severity: 'high',
        action: `Start the ${ctx.displayName} service`,
        steps: [
          `Run: net start "${ctx.serviceName}"`,
          'Check Event Log for failure reason',
          'Verify service account credentials',
          'Check dependencies'
        ]
      };

    case 'ransomware_ctx':
      return {
        severity: 'critical',
        action: 'IMMEDIATE: Isolate device and investigate',
        steps: [
          'Disconnect from network immediately',
          'Do NOT restart the device',
          'Contact security team',
          'Preserve evidence',
          'Check for lateral movement'
        ]
      };

    case 'online_offline_status_ctx':
      return {
        severity: ctx.offlineDuration > 60 ? 'high' : 'moderate',
        action: 'Verify device connectivity',
        steps: [
          'Ping device from network',
          'Check physical connectivity',
          'Verify no scheduled maintenance',
          'Contact on-site user if available'
        ]
      };

    default:
      return {
        severity: 'moderate',
        action: 'Review alert details',
        steps: ['Investigate alert context', 'Check device status']
      };
  }
}
```

See [references/examples.md](references/examples.md) for batch alert resolution and alert summary report examples.

## Error Handling

### Common Alert API Errors

| Error | Status | Cause | Resolution |
|-------|--------|-------|------------|
| Alert not found | 404 | Invalid alertUid | Verify alert exists |
| Already resolved | 400 | Alert already closed | Check alert state first |
| Permission denied | 403 | API restrictions | Check API permissions |

### Error Handling Pattern

```javascript
async function safeResolveAlert(client, alertUid, resolution) {
  try {
    await client.request(`/api/v2/alert/${alertUid}/resolve`, {
      method: 'POST',
      body: JSON.stringify({ resolution })
    });
    return { success: true };
  } catch (error) {
    if (error.status === 404) {
      return { success: false, reason: 'Alert not found - may already be resolved' };
    }
    if (error.status === 400) {
      return { success: false, reason: 'Alert already resolved' };
    }
    throw error;
  }
}
```

## Best Practices

1. **Prioritize by severity** - Handle Critical and High alerts first
2. **Use context data** - Each @class has specific actionable fields
3. **Document resolutions** - Include what was done and outcome
4. **Set up escalation** - Auto-escalate stale high-priority alerts
5. **Monitor patterns** - Repeated alerts may indicate larger issues
6. **Use site filtering** - Scope alerts to relevant sites when possible
7. **Handle ransomware specially** - Immediate isolation protocol
8. **Track resolution time** - Measure alert-to-resolution duration
9. **Correlate alerts** - Multiple alerts may share root cause
10. **Review resolved alerts** - Learn from past incidents

## Alert Priority Matrix

| Context Type | Typical Priority | Notes |
|--------------|-----------------|-------|
| `ransomware_ctx` | Critical | Always immediate action |
| `online_offline_status_ctx` (server) | High | Business impact |
| `perf_disk_usage_ctx` (>95%) | High | Data loss risk |
| `srvc_status_ctx` (critical service) | High | Service impact |
| `antivirus_ctx` (threat detected) | High | Security risk |
| `perf_resource_usage_ctx` | Moderate | Performance impact |
| `patch_ctx` (critical patches) | Moderate | Security debt |
| `eventlog_ctx` | Varies | Based on event severity |
| `sw_action_ctx` | Low | Informational |

## Related Skills

- [Datto RMM Devices](../devices/SKILL.md) - Device management
- [Datto RMM Sites](../sites/SKILL.md) - Site-level alert views
- [Datto RMM Jobs](../jobs/SKILL.md) - Remediation jobs
- [Datto RMM API Patterns](../api-patterns/SKILL.md) - Authentication and pagination