> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SmartBear AlertSite alert integration

> Send SmartBear AlertSite availability and performance alerts to Flashduty On-call through JSON alerts.

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.

<div className="hide">
  ## 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**
</div>

## Configure AlertSite

***

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Warning>
  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`.
</Warning>

## 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

***

| AlertSite `notify_type` | Flashduty status | Flashduty severity |
| :- | :- | :- |
| `error` (availability error) | Trigger | Critical |
| `perf_error` (response time over the error threshold, `status` `20`) | Trigger | Warning |
| `perf_warning` (response time over the warning threshold, `status` `10`) | Trigger | Info |
| `clear` | Recover | Critical |
| `perf_clear` | Recover | Warning |
| `test` | Separate Info alert | Info |

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](https://support.smartbear.com/alertsite/docs/alerts/delivery/json.html) and [Alert Data Fields](https://support.smartbear.com/alertsite/docs/alerts/fields.html).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.