Tactical RMM alert integration

Use a webhook action in a Tactical RMM (self-hosted, open-source RMM) alert template to send agent-overdue, check, and task failure alerts to Flashduty On-call. Each Tactical RMM alert maps to one Flashduty alert: it is created on failure and recovers when Tactical RMM resolves it. Tactical RMM has no fixed webhook payload; you write the request body yourself. This page gives the JSON template to paste, and Flashduty parses the fields of that template.

Configure Tactical RMM

Create two webhooks, one for failure and one for recovery, then attach both to an alert template. Both webhooks use the Flashduty push URL, and the request bodies differ only in status.

Create the failure webhook in Tactical RMM

Where: Tactical RMM › Settings › Global Settings › Web Hooks › Add Web HookUse the Web Hooks tab, not URL Actions.

Field	Value	Required
URL Pattern	`{integration_url}`	Required
Request method	POST	Required
Request Headers	See below	Required
Request Body	See below, with `status` set to `firing`	Required

Request Headers:

{ "Content-Type": "application/json" }

Request Body:

{
  "status": "firing",
  "alert_id": "{{alert.id}}",
  "alert_type": "{{alert.alert_type}}",
  "severity": "{{alert.severity}}",
  "message": "{{alert.message}}",
  "hostname": "{{agent.hostname}}",
  "agent_id": "{{agent.agent_id}}",
  "client": "{{agent.site.client.name}}",
  "site": "{{agent.site.name}}"
}

Create the recovery webhook in Tactical RMM

Where: Tactical RMM › Settings › Global Settings › Web Hooks › Add Web Hook

Field	Value	Required
URL Pattern	`{integration_url}`	Required
Request method	POST	Required
Request Headers	Same as the previous step	Required
Request Body	Identical to the previous step, except the first line becomes `"status": "resolved"`	Required

Without the recovery webhook, Flashduty alerts do not recover automatically.

Attach the webhooks to an alert template in Tactical RMM

Where: Tactical RMM › Settings › Alerts Manager

Field	Value	Required
Alert template	Create or edit the template used for on-call alerts	Required
Alert Failure Settings	Choose Send a Web Hook and select the failure webhook in Failure Web Hook	Required
Alert Resolved Settings	Choose Send a Web Hook and select the recovery webhook in Resolved Web Hook	Required
Agent, check, and task settings	Enable the alerts you need and apply the template to the clients, sites, or policies you want	Required

Tactical RMM runs webhooks for Error alerts (such as an overdue agent) and Warning alerts by default. Info alerts are not sent unless you tick Informational Alerts under Receive notifications on in Settings › Global Settings › General.

Save and verify

Where: Tactical RMM › Settings › Global Settings › Web Hooks › Test

On the webhook edit page, click Test with the target type set to None (no agent, site, or client). Flashduty creates an Info alert titled Tactical RMM test notification. It does not recover on its own, so close it manually after verifying. The Tactical RMM documentation says {{alert.XXX}} variables are not available in test mode. If you select a target, the variables may be replaced with other values, and Flashduty rejects the request because alert_type is invalid. So Test only proves connectivity; verify with a real alert
Trigger a real alert (for example, stop a test agent) and confirm Flashduty receives an active alert
After the alert recovers, confirm the matching Flashduty alert recovers

Event types

Request body	Effect in Flashduty
`status` is `firing`	Triggers an alert
`status` is `resolved`	Recovers the alert
Test button (`alert_id` and `alert_type` are still the unrendered `{{alert.id}}` and `{{alert.alert_type}}`)	Creates a separate Info alert that does not recover

Alert key

Flashduty computes the Alert Key from alert_id ({{alert.id}}, the number of the alert record in Tactical RMM). The failure and recovery webhooks render from the same record, so the number is the same. If the same subject fails again after recovery, Tactical RMM creates a new alert record, so it is a new alert in Flashduty. Changes to severity, message, or hostname do not change the Alert Key, and requests without alert_id are rejected. Use one Flashduty integration per Tactical RMM instance. Alert numbers from different instances can collide.

Status and severity

Tactical RMM `severity`	Flashduty severity
`error`	Critical
`warning`	Warning
`info`	Info
Anything else or empty	Warning

When status is resolved the alert recovers and keeps its last severity.

Labels

Label	Source
`check` / `alert_type`	Alert type (`availability`, `check`, `task`, `custom`)
`resource` / `host`	Agent hostname (`hostname`)
`alert_id`	Tactical RMM alert number
`severity`	Original Tactical RMM severity
`agent_id`	Agent ID
`client` / `site`	Client and site the agent belongs to

Troubleshooting

Flashduty returns an invalid-parameter error: the message names the field. Common causes are a request body without alert_id, or an alert_type other than availability, check, task, or custom (for example, when a test target was selected on the Test button)
The alert does not recover: confirm the recovery webhook exists, is set as the Resolved Web Hook of the alert template, and sends "status": "resolved". The action result is visible in the alert details in Tactical RMM
Flashduty receives nothing: confirm the alert template is applied to the agent and the alert severity is not filtered out by the Info and Warning notification switches
The request body is not valid JSON: if {{alert.message}} contains double quotes, the JSON that Tactical RMM renders is invalid and Flashduty rejects it. Remove the message line from the template and Flashduty builds the title from the alert type and hostname
The test alert stays open: the Test button does not send a recovery, so close it manually

For more variables, see the Tactical RMM alerting and webhook documentation.

Quick Start

Product Comparison

Channels

Incident Management

Post-Mortem

Status Page

Analytics

Integration Settings

Configuration

Advanced

Integrations

Best Practices