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.

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 fati