SuperOps.ai Alert Management

Overview

SuperOps.ai RMM generates alerts when monitored conditions are triggered on managed assets. Alerts can indicate hardware issues, software problems, security events, or custom monitoring conditions. This skill covers alert listing, filtering, acknowledgment, resolution, and automated workflows.

Anti-triggers

• The customer-facing work an alert becomes — use

superops-tickets; the conversion is described here but the ticket lifecycle is not.

• Alerts from a different RMM — atera-alerts,

ninjaone-alerts, datto-rmm-alerts, and N-central active issues (ncentral-monitoring-tasks) are separate stores with their own severity scales.

• Security detections — EDR and MDR findings are not RMM alerts; use

huntress-incidents, sentinelone-alerts, or rocketcyber-incidents.

• Fixing what the alert reports — remediation runs through

superops-runbooks; resolving an alert does not fix a machine.

Alert Severity Levels

Alert Status Values

Common Alert Types

Key Alert Fields

An alert carries alertId, message, severity, status, type, and the createdTime/acknowledgedTime/resolvedTime timestamps. It associates to an asset, client, site, the triggering monitor, and optionally a linked ticket. Resolution metadata lives in acknowledgedBy, resolvedBy, and resolutionNotes.

See references/fields.md for the complete field reference.

GraphQL Operations

Both mutations take arrays (alertIds), so a single call handles bulk acknowledgment or resolution. getAlertList returns a listInfo block (totalCount, hasNextPage, endCursor) for cursor pagination.

Filters accept either a scalar or an array for status and severity ("status": "Active" and "status": ["Active", "Acknowledged"] are both valid), and createdTime supports gte/lte range operators.

See references/api.md for the full operation catalog with request shapes and variable examples.

Common Workflows

Alert Triage Workflow

1. Query getAlertList filtered to status: "Active", severity: "Critical",

ordered by createdTime ascending (oldest first).

1. acknowledgeAlerts on the alert being worked, with investigation notes.
2. createTicketFromAlert if the issue needs tracked service delivery.
3. resolveAlerts with resolutionNotes once fixed.

Alert Summary Dashboard

Use GraphQL query aliases to fetch several counts in a single request — active Critical, active High, Acknowledged, and recently Resolved — each reading only listInfo { totalCount }.

Client Alert Report

Filter getAlertList by client.accountId plus a createdTime gte/lte range to produce a period report of alerts raised and resolved.

See references/api.md for all three workflow queries.

Error Handling

Common Errors

Status Transition Rules

// Valid alert status transitions
const validTransitions = {
  'Active': ['Acknowledged', 'Resolved'],
  'Acknowledged': ['Resolved', 'Active'],  // Can un-acknowledge
  'Resolved': ['Active'],  // Can reopen if issue returns
  'Auto-Resolved': ['Active']  // Can reopen
};

function canTransition(currentStatus, newStatus) {
  return validTransitions[currentStatus]?.includes(newStatus) || false;
}

Best Practices

1. Acknowledge promptly - Show clients issues are being tracked
2. Create tickets for complex issues - Link alert to ticket for tracking
3. Document resolutions - Helps with recurring issues
4. Use bulk operations - One alertIds array beats N calls
5. Set up auto-resolution - Let transient issues clear themselves
6. Monitor acknowledgment time - Track response SLAs
7. Review alert patterns - Identify recurring problems

Related Skills

• SuperOps.ai Assets - Asset details
• SuperOps.ai Tickets - Create tickets from alerts
• SuperOps.ai Runbooks - Automated remediation
• SuperOps.ai Clients - Client associations
• SuperOps.ai API Patterns - GraphQL patterns