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

Alert States

Field Reference

Alert Object

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.

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

API Patterns

Get All Open Alerts

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

Get Open Alerts for Site

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

Get Open Alerts for Device

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

Get Resolved Alerts

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

Get Alerts Since Timestamp

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

Resolve an Alert

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

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

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 for batch alert resolution and alert summary report examples.

Error Handling

Common Alert API Errors

Error Handling Pattern

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

Related Skills

• Datto RMM Devices - Device management
• Datto RMM Sites - Site-level alert views
• Datto RMM Jobs - Remediation jobs
• Datto RMM API Patterns - Authentication and pagination