Configured alerts versus system alerts

Differences

Configured alerts	System alerts
Created and managed by you (or your admin/team) to match your operational needs.	These are generated by Digi Remote Manager automatically. They’re meant to notify you about internal processing conditions (not device telemetry rules you define).
Distinctions You choose the trigger: the condition, thresholds, and any timing like delays/persistence (to avoid flapping). You choose the scope: which devices/groups the alert applies to. You choose the actions: who gets notified (and how), and how you want to operationalize it (runbooks, ticketing via webhook/API, etc.). You manage the lifecycle: you can tune, disable, delete, acknowledge, and reset them based on your workflow.	Distinctions Not customer-configured triggers: the conditions and thresholds are defined by the platform. More “informational/administrative” in nature: they tend to indicate something about processing, status, or limits rather than a device sensor threshold you set. Less control: you typically can’t edit the underlying “rule,” though you may be able to acknowledge/clear or manage notification preferences depending on the DRM UI/API surface. Used to protect operations: they often exist to highlight conditions that could affect data freshness, processing, or your ability to manage devices (think “account needs attention” style signals, rather than “device KPI crossed threshold”).
Typical examples Device offline Cellular signal below X Data usage above Y Temperature above Z VPN down	Typical examples Account or licensing state issues Usage/limits/quota Platform processing or workflow issues Connectivity/ingestion anamolies

Configured alerts

System alerts

Created and managed by you (or your admin/team) to match your operational needs.

These are generated by Digi Remote Manager automatically. They’re meant to notify you about internal processing conditions (not device telemetry rules you define).

Distinctions

You choose the trigger: the condition, thresholds, and any timing like delays/persistence (to avoid flapping).
You choose the scope: which devices/groups the alert applies to.
You choose the actions: who gets notified (and how), and how you want to operationalize it (runbooks, ticketing via webhook/API, etc.).
You manage the lifecycle: you can tune, disable, delete, acknowledge, and reset them based on your workflow.

Distinctions

Not customer-configured triggers: the conditions and thresholds are defined by the platform.
More “informational/administrative” in nature: they tend to indicate something about processing, status, or limits rather than a device sensor threshold you set.
Less control: you typically can’t edit the underlying “rule,” though you may be able to acknowledge/clear or manage notification preferences depending on the DRM UI/API surface.
Used to protect operations: they often exist to highlight conditions that could affect data freshness, processing, or your ability to manage devices (think “account needs attention” style signals, rather than “device KPI crossed threshold”).

Typical examples

Device offline
Cellular signal below X
Data usage above Y
Temperature above Z
VPN down

Typical examples

Account or licensing state issues
Usage/limits/quota
Platform processing or workflow issues
Connectivity/ingestion anamolies

Similarities

They “fire” when a defined condition exists and “reset/clear” when it’s resolved (i.e., they have an alarm lifecycle/state).
They both appear in the alerts list on the Lists tab.
They are retrievable via the API (alerts are listable/manageable objects in DRM).
They can be acknowledged (acknowledgment is supported as a state/action on a triggered alert).