Skip to main content
Use the Execute HTTP Action of PRTG notification templates to send sensor state alerts and recoveries to Flashduty On-call. Each PRTG sensor maps to one Flashduty alert: the alert triggers when a state trigger fires, repeated notifications merge into the same alert, and the alert recovers when the sensor leaves that state. Both PRTG Network Monitor (self-hosted) and PRTG Hosted Monitor can be configured as described here.

​
In Flashduty On-call

You can get the integration push URL in either of the following ways.

​
Use a dedicated integration

  1. In the Flashduty console, go to Channels and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select PRTG and click Save
  4. Open the new integration card and copy the push URL

​
Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select PRTG and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routes after creation
  4. Click Save and copy the generated push URL

​
Configure PRTG

PRTG needs two notification templates: one sent when a sensor enters an alert state (event=trigger) and one sent when it leaves that state (event=resolve). Both templates use the same push URL and the same fields; only the leading event differs.
1

Create the alert notification template

  1. Sign in to PRTG as an administrator, go to Setup → Account Settings → Notification Templates, and click Add Notification Template
  2. Enter Flashduty alert as the Template Name
  3. Select Execute HTTP Action and fill it in as follows:
Alert template:
  1. Click Create
2

Create the recovery notification template

Create a second template the same way. Enter Flashduty recovery as the Template Name and use the recovery template below as the Payload; keep every other setting the same:
You can send a test notification for a template from the Notification Templates list to check the URL. PRTG does not resolve placeholders in test notifications; Flashduty recognizes them, answers with success, and creates no alert.
3

Add a state trigger

  1. Open the object to connect (the Root group, a group, a device, or a sensor), go to the Notification Triggers tab, and select Add State Trigger
  2. Fill it in as follows:
  1. Save the trigger. Child groups, devices, and sensors inherit it
To also receive alerts for the Warning or Unusual status, add one state trigger per status with the same perform and no longer … perform choices. If you use the optional escalation notification (the second When sensor status is … for at least … seconds line), select Flashduty alert for it too; it merges into the same alert.
4

Verify the lifecycle

Put a sensor into the Down state for real (for example, briefly cut the network to the address a Ping sensor checks), wait for the trigger latency, and confirm that Flashduty receives an active alert. After the sensor recovers, confirm that the same alert is closed.
sensorid and event are required. Paste the whole template without removing or renaming fields. When sensorid or event is missing, Flashduty returns a parameter error, because the recovery notification could not otherwise be matched to the original alert.

​
Payload fields

PRTG posts the template fields as an application/x-www-form-urlencoded form. Each field is named after the PRTG placeholder that fills it: The alert title is <device name>: <sensor name>. If the device name is empty, Flashduty uses the sensor name alone; if both are empty, it uses PRTG sensor <sensorid>.

​
Alert Key

Flashduty uses sensorid as the Alert Key. Alert, escalation, and recovery notifications for the same sensor carry the same sensor ID, so they land on the same alert. Two sensors with the same name on one device have different IDs and produce different alerts. Changing the sensor name, device name, status, or message does not change the Alert Key. Sensor IDs are unique only within one PRTG server. Use a separate Flashduty integration for each PRTG server, so that sensors with the same ID on different servers do not merge into one alert.

​
Status and severity

event decides whether the alert triggers or recovers, and laststatus decides the severity: Requests with an empty or any other event are rejected, so a request whose state cannot be determined never enters the wrong alert lifecycle.

​
FAQ

No PRTG placeholder tells whether a notification comes from a state trigger firing or from its no longer recovery, so the fixed event value in the template says it. laststatus only describes the sensor’s current status: when a sensor moves from Down to Warning, the Down trigger’s recovery notification carries laststatus Warning. Deciding recovery by event closes each trigger’s alert on time.
The Down trigger sends its recovery notification, which closes the Down alert. If a Warning state trigger is configured, it sends an alert notification after its latency and reopens an alert for the sensor with Warning severity.
The laststatus value PRTG sends is translated with the PRTG language setting. Flashduty recognizes English status names only and treats any other status name as Warning. Triggering and recovery are decided by event and do not depend on the language.
Check that SNI Handling is set to Send SNI and that SNI Name matches the host name in the push URL. Without SNI, the request may never reach Flashduty while PRTG still reports success.
PRTG sends placeholders it does not know as literal text. %laststatus needs PRTG 20.1.57 or later, and %tags needs 20.1.56 or later. On older versions, an alert whose laststatus is literal text is treated as Warning; the other fields only affect labels, not triggering or recovery.

​
Troubleshooting

  • PRTG fails to send: check that the URL is the complete push URL including integration_key, and that HTTP Method is POST
  • Flashduty returns a parameter error: check that the Payload contains the whole template on one line, including event and sensorid
  • The alert does not recover: check that the state trigger’s no longer … perform uses the Flashduty recovery template, and that the recovery and alert notifications come from the same sensor
For placeholder details, see the PRTG manual pages List of Placeholders for Notifications and Notification Templates.