Atera Alerts

Atera Alert Management

Overview

Alerts in Atera are notifications generated when monitored systems exceed defined thresholds or encounter issues. They serve as the early warning system for MSPs, enabling proactive response to client issues before they become critical problems.

Anti-triggers

• The work the alert generated — an alert promoted into a service desk record is a ticket; use atera-tickets.
• What raises the alert — thresholds and monitor configuration are atera-devices for agentless monitors and atera-agents for endpoint health.
• Alerts from a different RMM — superops-alerts, ninjaone-alerts, datto-rmm-alerts, connectwise-automate-alerts, and N-central active issues (ncentral-monitoring-tasks) are separate stores with their own severity scales. Nothing here reads them, and the counts are not comparable.
• A security detection — endpoint threat findings come from the EDR, not the RMM; use huntress-incidents, sentinelone-alerts, or rocketcyber-incidents.

Alert Severity Levels

Alert Sources

Alert Types

Alert Fields

Core Fields

Device/Customer Fields

API Patterns

List All Alerts (Paginated)

GET /api/v3/alerts?page=1&itemsInPage=50
X-API-KEY: {api_key}

Response:

{
  "items": [
    {
      "AlertID": 111111,
      "Code": 205,
      "Source": "Agent",
      "Title": "High CPU Usage",
      "Severity": "Warning",
      "Created": "2024-02-15T10:30:00Z",
      "CustomerID": 12345,
      "CustomerName": "Acme Corporation",
      "DeviceName": "SERVER-DC01",
      "DeviceGuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "AlertMessage": "CPU usage exceeded 90% for 5 minutes",
      "Archived": false,
      "TicketID": null
    }
  ],
  "totalItems": 250,
  "page": 1,
  "itemsInPage": 50,
  "totalPages": 5
}

Get Alert by ID

GET /api/v3/alerts/{alertId}
X-API-KEY: {api_key}

Response:

{
  "AlertID": 111111,
  "Code": 205,
  "Source": "Agent",
  "Title": "High CPU Usage",
  "Severity": "Warning",
  "Created": "2024-02-15T10:30:00Z",
  "CustomerID": 12345,
  "CustomerName": "Acme Corporation",
  "DeviceName": "SERVER-DC01",
  "DeviceGuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "AlertMessage": "CPU usage has exceeded 90% threshold\n\nCurrent Value: 95%\nThreshold: 90%\nDuration: 5 minutes",
  "AdditionalInfo": "Process: sqlservr.exe consuming 85% CPU",
  "Archived": false,
  "ArchivedDate": null,
  "TicketID": null,
  "SnoozedEndDate": null,
  "AlertCategoryID": "performance"
}

Create Alert (API-Generated)

POST /api/v3/alerts
X-API-KEY: {api_key}
Content-Type: application/json

{
  "DeviceGuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "Title": "Custom Alert - Database Connection Pool Exhausted",
  "Severity": "Critical",
  "AlertMessage": "Application database connection pool at 100% capacity. New connections being rejected.",
  "AlertCategoryID": "application"
}

Response:

{
  "ActionID": 111112,
  "AlertID": 111112
}

Delete/Resolve Alert

DELETE /api/v3/alerts/{alertId}
X-API-KEY: {api_key}

Response:

{
  "ActionID": 111111,
  "Success": true
}

Alert to Ticket Conversion

Workflow

1. Review alert - Understand the issue
2. Create ticket - Link to alert for context
3. Assign technician - Route for resolution
4. Resolve issue - Fix the underlying problem
5. Close alert - Delete or archive when resolved

Create Ticket from Alert

POST /api/v3/tickets
X-API-KEY: {api_key}
Content-Type: application/json

{
  "TicketTitle": "Alert: High CPU Usage on SERVER-DC01",
  "Description": "Alert ID: 111111\n\nCPU usage has exceeded 90% threshold\n\nCurrent Value: 95%\nThreshold: 90%\nDuration: 5 minutes\n\nProcess: sqlservr.exe consuming 85% CPU",
  "CustomerID": 12345,
  "TicketPriority": "High",
  "TicketType": "Problem"
}

Alert Categorization

Performance Alerts

Availability Alerts

Security Alerts

Common Workflows

Alert Triage Process

1. Review new alerts - Sort by severity
2. Assess impact - Determine business effect
3. Prioritize response - Critical first
4. Take action - Resolve or escalate
5. Document - Create ticket if needed
6. Close - Delete resolved alerts

Alert Suppression

When an alert is expected (maintenance, known issue):

1. Snooze alert - Temporarily suppress
2. Set duration - Define snooze period
3. Document reason - Note why suppressed
4. Review after - Verify issue resolved

Bulk Alert Management

For multiple alerts from same issue:

1. Identify root cause - Find common source
2. Create single ticket - Link all related alerts
3. Resolve root cause - Fix underlying issue
4. Bulk delete - Remove all related alerts

Error Handling

Common API Errors

Alert Processing Errors

Best Practices

1. Respond quickly to critical alerts - Time is essential
2. Set appropriate thresholds - Avoid alert fatigue
3. Review alert patterns - Identify recurring issues
4. Convert to tickets - Track resolution formally
5. Document resolutions - Build knowledge base
6. Tune alert profiles - Reduce false positives
7. Use severity appropriately - Reserve Critical for urgent issues
8. Archive rather than delete - Maintain history for trends

Alert Monitoring Dashboard

Key Metrics to Track

Related Skills

• Atera Agents - Agent-generated alerts
• Atera Devices - Device monitor alerts
• Atera Tickets - Alert to ticket conversion
• Atera API Patterns - Authentication and pagination