Alerts

---
name: "NinjaOne Alerts"
description: >
  NinjaOne alerts and the conditions behind them: retrieving device alerts,
  dismissing individual alerts and bulk resets, alert summaries, severity and
  priority levels, common hardware/service/security/connectivity alert types and
  thresholds, alert webhooks, and triage workflows.
when_to_use: >-
  When reviewing, triaging, or clearing NinjaOne device alerts and conditions. Use when:
  ninjaone alert, ninjarmm alert, ninja condition, device alert ninja, dismiss alert
  ninja, clear alert ninja, critical alert ninja, bulk dismiss alerts ninja, alert
  summary ninja, ninjaone alert count, or alerts by severity ninja.
---

# NinjaOne Alert Management

## Overview

Alerts in NinjaOne indicate conditions on devices that require attention. They're generated by monitoring policies when thresholds are exceeded or conditions are detected.

## Anti-triggers

- **An alert from a different RMM** — use `atera-alerts`,
  `datto-rmm-alerts`, or `connectwise-automate-alerts`. All of them say
  "alert" and "critical"; only the source platform disambiguates.
- **Turning an alert into work someone owns** — an alert is not a ticket.
  Use `ninjaone-tickets` for NinjaOne's own queue, or the PSA's skill
  (`autotask-tickets`, `connectwise-psa-tickets`, `halopsa-tickets`) when
  the ticket lives there.
- **Deciding priority and routing for an incoming ticket** — that is
  triage practice, not alert retrieval; use `shared-skills-ticket-triage`.
- **A security detection rather than a monitoring condition** — endpoint
  threat detections belong to the security stack; use
  `huntress-incidents` or the relevant EDR skill.

## Alert vs Condition

- **Condition**: An active state on a device (e.g., disk space low)
- **Alert**: A notification generated when a condition is triggered

Conditions persist until resolved; alerts can be dismissed independently.

## API Endpoints

### Get Device Alerts

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

Returns active alerts for a specific device.

### Reset/Dismiss Alert

```http
DELETE /api/v2/alert/{uid}
Authorization: Bearer {token}
```

Dismisses an alert by its unique identifier. The underlying condition may still exist if not resolved.

### Reset All Alerts (Bulk Dismiss)

Tool: `ninjaone_alerts_reset_all`

Dismisses all alerts for a specific device or organization. Use with care — this cannot be undone.

Key parameters:
- `device_id` — Reset all alerts for a single device
- `organization_id` — Reset all alerts for an entire organization
- `severity` — Optionally limit to a specific severity level: `CRITICAL`, `MAJOR`, `MINOR`, or `NONE`

At least one of `device_id` or `organization_id` must be provided. Typically used after scheduled maintenance windows to clear expected alerts.

### Get Alert Summary

Tool: `ninjaone_alerts_summary`

Returns a count of active alerts grouped by severity and/or organization.

Key parameter:
- `group_by` — How to group counts: `"severity"` (default), `"organization"`, or `"both"`

Useful for dashboards and morning briefings to understand the overall alert posture at a glance without retrieving individual alerts.

## Alert Structure

```json
{
  "uid": "alert-uuid-12345",
  "deviceId": 123,
  "message": "Disk space on C: below 10%",
  "severity": "CRITICAL",
  "priority": "HIGH",
  "sourceType": "CONDITION",
  "sourceConfigUid": "condition-config-id",
  "createTime": "2024-02-15T10:30:00Z"
}
```

## Severity Levels

| Severity | Description | Typical Response |
|----------|-------------|------------------|
| `CRITICAL` | Service impacting, requires immediate attention | Immediate |
| `MAJOR` | Significant issue, high priority | Within 1 hour |
| `MODERATE` | Notable issue, medium priority | Within 4 hours |
| `MINOR` | Low impact issue | Within 24 hours |
| `NONE` | Informational only | As time permits |

## Priority Levels

| Priority | Description |
|----------|-------------|
| `HIGH` | Escalate immediately |
| `MEDIUM` | Standard priority |
| `LOW` | Address when convenient |
| `NONE` | No action required |

## Common Alert Types

### Hardware Alerts

| Condition | Typical Threshold | Severity |
|-----------|-------------------|----------|
| Disk space low | < 10% free | CRITICAL |
| Disk space warning | < 20% free | MAJOR |
| Memory pressure | > 90% used | MAJOR |
| CPU sustained high | > 95% for 15 min | MODERATE |
| SMART disk warning | Any SMART error | MAJOR |

### Service Alerts

| Condition | Description | Severity |
|-----------|-------------|----------|
| Service stopped | Critical service not running | CRITICAL |
| Service restart loop | Multiple restarts detected | MAJOR |
| Service degraded | Running but errors detected | MODERATE |

### Security Alerts

| Condition | Description | Severity |
|-----------|-------------|----------|
| Antivirus disabled | Protection not running | CRITICAL |
| Definitions outdated | AV definitions old | MAJOR |
| Failed login attempts | Multiple failures | MODERATE |
| Firewall disabled | Windows firewall off | MAJOR |

### Connectivity Alerts

| Condition | Description | Severity |
|-----------|-------------|----------|
| Device offline | No agent contact | CRITICAL |
| Intermittent connection | Frequent reconnects | MODERATE |
| High latency | Network performance issues | MINOR |

## Webhooks for Alerts

Configure webhooks to receive real-time alert notifications:

### Configure Webhook

```http
PUT /api/v2/webhook
Content-Type: application/json
```

```json
{
  "url": "https://your-server.com/webhook/ninjaone",
  "events": ["ALERT_TRIGGERED", "ALERT_CLEARED"]
}
```

### Remove Webhook

```http
DELETE /api/v2/webhook
```

### Webhook Payload

```json
{
  "event": "ALERT_TRIGGERED",
  "alert": {
    "uid": "alert-uuid",
    "deviceId": 123,
    "message": "Disk space critical",
    "severity": "CRITICAL"
  },
  "device": {
    "id": 123,
    "displayName": "SERVER-01",
    "organizationId": 456
  },
  "timestamp": "2024-02-15T10:30:00Z"
}
```

## Common Workflows

### Daily Alert Review

1. Query alerts across all devices
2. Filter by severity (CRITICAL first)
3. Review each alert context
4. Take action or dismiss
5. Document resolution

### Alert Triage

1. Check severity and priority
2. Identify affected device and org
3. Determine if automated fix possible
4. Create ticket if manual intervention needed
5. Dismiss alert after resolution

### Mass Alert Dismissal

After scheduled maintenance:
1. Filter alerts by time range
2. Identify maintenance-related alerts
3. Bulk dismiss expected alerts
4. Review remaining alerts

## Best Practices

1. **Don't ignore alerts** - Address or dismiss, never leave stale
2. **Set appropriate thresholds** - Avoid alert fatigue
3. **Document dismissals** - Note why alert was cleared
4. **Review periodically** - Audit alert policies quarterly

## Error Handling

| Code | Description | Resolution |
|------|-------------|------------|
| 404 | Alert not found | May already be dismissed |
| 403 | Access denied | Check organization permissions |
| 400 | Invalid request | Verify alert UID format |

## Related Skills

- [Devices](../devices/SKILL.md) - Device management
- [Tickets](../tickets/SKILL.md) - Create tickets from alerts
- [API Patterns](../api-patterns/SKILL.md) - Authentication