Datto RMM alert integration

Use a Datto RMM webhook to send device alerts to Flashduty On-call. Each Datto RMM alert maps to one Flashduty alert. When an alert resolves automatically, Datto RMM’s “alert resolved” request closes the same Flashduty alert. Datto RMM sends a request body that you write yourself, so paste the JSON templates below into Datto RMM.

Configure Datto RMM

You can configure the webhook on a single monitor’s response settings or globally. Turning on Global Webhooks automatically disables the webhooks set on individual monitors, so use one or the other.

Set the URL and format

Global webhook
Single monitor

Where: Datto RMM › Setup › Integrations › Global WebhooksIn Details, click Turn On next to Enable Webhooks globally for Monitors, then fill in:

Field	Value
Alert priorities to send as webhooks (Required)	The alert priorities that should send webhooks; multiple selection is allowed
URL (Required)	`{integration_url}` (500 characters at most)
Content Type (Required)	`application/json`

Where: Datto RMM › the monitor’s response details › Send a Webhook

Field	Value
URL (Required)	`{integration_url}` (500 characters at most)
Content Type (Required)	`application/json`

Set the alert-raised payload

Where: Datto RMM › Setup › Integrations › Global Webhooks › When alert is raised; for a single monitor, response details › Send a WebhookPaste this into the When alert is raised payload:

{
  "event": "triggered",
  "alert_uid": "[alert_uid]",
  "alert_type": "[alert_type]",
  "alert_category": "[alert_category]",
  "alert": "[alert]",
  "alert_message": "[alert_message_en]",
  "device_uid": "[device_uid]",
  "device_hostname": "[device_hostname]",
  "device_os": "[device_os]",
  "device_ip": "[device_ip]",
  "site_name": "[sitename]",
  "platform": "[platform]",
  "severity": "Critical"
}

severity is an optional fixed value. The variables listed in the Datto RMM documentation include no priority variable (a Teams template uses [alert_priority], but the documentation does not list it and it is unverified). A global webhook shares one payload across all priorities, so it can only carry one fixed value; to set the severity by priority, use a single-monitor webhook and write a different severity in each monitor. Without it the alert is Warning. Accepted values are Critical, High, Moderate, Low, and Information.

Set the alert-resolved payload

Where: Datto RMM › Setup › Integrations › Global Webhooks › When alert is resolved (optional); for a single monitor, response details › Send a WebhookTurn on When alert is resolved (optional) and use the same payload with event set to resolved; severity can be omitted. Without this toggle Flashduty never receives a recovery.

{
  "event": "resolved",
  "alert_uid": "[alert_uid]",
  "alert_type": "[alert_type]",
  "alert_category": "[alert_category]",
  "alert": "[alert]",
  "alert_message": "[alert_message_en]",
  "device_uid": "[device_uid]",
  "device_hostname": "[device_hostname]",
  "device_os": "[device_os]",
  "device_ip": "[device_ip]",
  "site_name": "[sitename]",
  "platform": "[platform]"
}

Keep event and alert_uid. Flashduty rejects a request without alert_uid because it could not match the later recovery, and event must be triggered or resolved. Datto RMM substitutes variables inside JSON strings, so a double quote in an alert message can break the JSON. If that happens, remove alert_message and alert.

Test and verify

Where: Datto RMM › Setup › Integrations › Global Webhooks › Test Alert (Raised/Resolved) Webhook; for a single monitor, Test WebhookClick the test button to confirm Datto RMM can send. When both payloads are set, they are sent together. The test uses your template, so Flashduty cannot tell it apart from a real alert and creates a normal alert; close it by hand afterwards. The test may carry unreplaced variable names (reported by third parties, unverified). Then let a real alert fire and resolve and confirm the Flashduty alert closes.After a few seconds, go back to Flashduty. If the integration shows a Latest event time, the setup works.

Alert key

Flashduty uses alert_uid (the Datto RMM variable [alert_uid], documented as “The alert ID”) as the Alert Key. The alert-raised and alert-resolved payloads use the same variable, so they refer to the same alert. Changes to device, site, alert type, message, or severity do not change the Alert Key.

Status and severity

`event`	Flashduty status
`triggered`	Triggered; severity comes from `severity`
`resolved`	Recovered

`severity`	Flashduty severity
`Critical`	Critical
`High`, `Moderate`	Warning
`Low`, `Information`	Info
Empty or other	Warning

About recovery

Datto RMM sends the resolved payload only when an alert resolves automatically; resolving an alert manually in the console sends nothing. Turn on auto-close after timeout in the channel that receives these alerts, with a suggested duration of 24 hours, so manually resolved alerts do not stay open.

Troubleshooting

Flashduty returns an invalid-parameter error: Check that the payload is valid JSON, alert_uid is not empty, and event is triggered or resolved
The alert does not recover: Check that When alert is resolved (optional) is on and uses the resolved template; manually resolved alerts send no recovery
A monitor’s own webhook stopped sending: Global Webhooks is on, which disables webhooks set on individual monitors
Payload too large: Datto RMM limits a payload to 64 KB, so shorten the template

Quick Start

Product Comparison

Channels

Incident Management

Post-Mortem

Status Page

Analytics

Integration Settings

Configuration

Advanced

Integrations

Best Practices

Datto RMM alert integration

In Flashduty On-call

Configure Datto RMM

Alert key

Status and severity

About recovery

Troubleshooting