NinjaOne Alerts

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.

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

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

Returns active alerts for a specific device.

Reset/Dismiss Alert

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

{
  "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

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

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

Remove Webhook

DELETE /api/v2/webhook

Webhook Payload

{
  "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. Use webhooks - Get real-time notifications
5. 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 - Device management
• Tickets - Create tickets from alerts
• API Patterns - Authentication