Skip to main content
Use AlertSite JSON alerts (POST JSON request to web server) to send monitor availability and performance alerts to Flashduty On-call. The availability problem and the performance problem of each AlertSite monitor each map to one Flashduty alert: it triggers on an error and recovers automatically when AlertSite sends the clear.

​
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, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select SmartBear AlertSite and click Save
  4. Open the new integration card and copy the Push URL

​
Use a shared integration

  1. In the Flashduty console, select Integration Center → Alert Events
  2. Select SmartBear AlertSite 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 AlertSite

1

Create a JSON alert recipient

  1. Sign in to AlertSite UXM and go to Alerts → Alert Recipients in the top right corner (Notifiers → Notifiers in AlertSite 1.0)
  2. Add a recipient and set Method to POST JSON request to web server
  3. In Recipient, paste the full Flashduty push URL (starting with https:// and including integration_key)
  4. Save the recipient
Only Admin, Co-Admin, and Power Users can edit recipients. By default a recipient gets alerts from all monitors. To limit it to some monitors, use AlertSite recipient groups.
2

Choose alert types and turn on clear notifications

Edit the recipient you just created:
  • Availability alerts: select Enabled and check Alert whenever an error clears. Without it AlertSite sends no clear, and the Flashduty alert never recovers automatically
  • Performance alerts (optional): select Enabled and set Type to Errors only or Warnings and errors. AlertSite sends perf_clear when the response time is back to normal
  • Set Alert after this # of consecutive errors and Stop alerting after this # of consecutive alerts as needed. Repeated alerts sent while an error continues merge into the same Flashduty alert
Performance alerts are off by default. Enable them and set thresholds on the monitor’s Alerts tab.
3

Send a test alert

In the recipient settings, use Send test notification and pick a monitoring location. The test alert has notify_type test. Flashduty opens a separate Info alert for each test. It never merges into a real alert and does not recover, so close it manually.
Use the default JSON alert template. This integration reads the field names of the default template. If the JSON recipient uses a custom alert template, or a recipient group assigns one, the fields may not be recognized, and Flashduty rejects requests without notify_type or device_id.

​
Alert Key

Flashduty computes the Alert Key from the alert type (availability or performance) and device_id. The AlertSite docs note that monitor names can change and recommend device_id as the identifier. The error and clear alerts of a monitor carry the same device_id, so they land on the same alert. Availability alerts (error / clear) and performance alerts (perf_warning / perf_error / perf_clear) are keyed separately: a performance clear does not close an availability alert that is still failing. Changes to the monitor name, failing location, failing step, status code, time, or response time do not change the Alert Key. Flashduty rejects a request without device_id, because the later recovery could not be matched.

​
Status and severity

An empty or other notify_type is rejected, so a request whose state cannot be determined never lands in the wrong alert lifecycle.

​
Alert content

  • Title: the monitor name device_name
  • Description: status text, failing location, URL, HTTP status, failing step, check time; the status of each location for rotated locations (rotated_locations); the response time and threshold of each location for performance alerts (locations)
  • Labels: device_id, device_type, custid, notify_type, alert_type (availability or performance), status_code (the AlertSite status code, 0 means OK), status_text, location, location_num, http_status, check (monitor name), resource (the monitored URL), and source (always alertsite)

​
Troubleshooting

  • AlertSite delivery fails: make sure Recipient holds the full push URL, including https:// and integration_key
  • Flashduty returns a parameter error: make sure the default template is used and the request has notify_type and device_id
  • The alert does not recover: make sure the recipient has Alert whenever an error clears checked and the monitor is really back to normal
  • No performance alerts arrive: make sure performance alerts are enabled on the monitor and the recipient’s Performance alerts is Enabled
  • Private locations: Private Node Server supports JSON alerts from version 2.1.2, and the push URL must be reachable from the private location
For field definitions, see AlertSite JSON Alerts and Alert Data Fields.