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

# Pingdom alert integration

> Send Pingdom uptime check and transaction check state changes to Flashduty On-call through a webhook.

Use Pingdom state change webhooks to send uptime check and transaction check alerts to Flashduty On-call. Each Pingdom check maps to one Flashduty alert: it triggers when the check fails and recovers automatically when the check is back.

<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 **Pingdom** 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 **Pingdom** 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 Pingdom

***

<Steps>
  <Step title="Create a webhook integration">
    1. Sign in to My Pingdom and go to **Settings → Integrations** (the gear icon in the left sidebar)
    2. Click **Add integration** in the top right corner and select **Webhook** as the type
    3. Name the integration `Flashduty`
    4. Paste the complete Flashduty integration Push URL into **URL**
    5. Click **Save integration**

    To send a test, edit a check (see the next step) and click **Test** next to the integration. The test is a `DOWN` for that check with `description` set to `test`. Flashduty answers with success and creates no alert.
  </Step>

  <Step title="Enable the integration on your checks">
    * **Uptime checks**: go to **Synthetics → Uptime**, for each check that should alert open the menu at the end of its row, click **Edit**, and select `Flashduty` in the integrations list
    * **Transaction checks**: edit each transaction check that should alert and select `Flashduty` in the integrations list of its alerting settings

    Pingdom sends a webhook only when a check changes state: uptime checks move between `UP` and `DOWN`, and transaction checks move between `SUCCESS` and `FAILING`. Nothing is resent while a check stays failed.

    The first result of a new check (unknown to `UP`) sends nothing. By default **When down, alert after** is 5 minutes, so the `DOWN` webhook arrives about 5 minutes after the check starts failing. Lower it in the check's alerting settings if you need faster alerts.
  </Step>

  <Step title="Verify the lifecycle">
    Make a check actually fail, for example by pointing it at an unreachable address for a moment, and confirm that Flashduty shows an active alert. Then restore the target and confirm that the same alert recovers.
  </Step>
</Steps>

<Tip>
  When the SolarWinds APM Integrated Experience is enabled, Pingdom menus may be in different places. Look for **Integrations** and the check's alerting settings.
</Tip>

## Alert Key

***

Flashduty computes the Alert Key from the check family (uptime or transaction) and `check_id`. The failure and recovery webhooks of one check carry the same `check_id`, so they land on the same alert. Uptime checks and transaction checks are separate check lists in Pingdom; including the family keeps them apart even when their numeric IDs are equal.

Changes to the check name, `importance_level`, state, timestamps, error description, or probe locations do not change the Alert Key. A request without `check_id` is rejected, because its recovery could not be matched.

## Status and severity

***

| Pingdom `current_state`       | Flashduty status |
| :---------------------------- | :--------------- |
| `DOWN` (uptime check)         | Triggered        |
| `FAILING` (transaction check) | Triggered        |
| `UP` (uptime check)           | Recovered        |
| `SUCCESS` (transaction check) | Recovered        |

An empty or any other `current_state` is rejected so that an ambiguous request cannot enter the wrong alert lifecycle.

Severity comes from the check's `importance_level`:

| Pingdom `importance_level`         | Flashduty severity |
| :--------------------------------- | :----------------- |
| `HIGH`                             | Critical           |
| `LOW`                              | Warning            |
| Empty (Pingdom defaults to `HIGH`) | Critical           |

A recovery keeps the alert's original severity.

## Alert content

***

* **Title**: the check name, `check_name`
* **Description**: `long_description`, or `description` when it is empty
* **Labels**: `check_id`, `check_name`, `check_type`, `importance_level`, `previous_state`, `current_state`, `hostname`, `full_url`, `url`, `tags` (comma-separated), `state_changed_timestamp`, `state_changed_utc_time`, `first_probe_location`, `second_probe_location`, `check` (the check name), `source` (always `pingdom`), and `resource` (`full_url`, then `hostname`, then `url`)

Request headers and authentication settings in `check_params` are not stored as labels.

## Troubleshooting

***

* **Pingdom receives a non-2xx response**: verify that the URL is the full Push URL and includes `integration_key`
* **Flashduty reports an invalid parameter**: verify that the request has `check_id` and `current_state`
* **The alert does not recover**: verify that the check is actually back to `UP` or `SUCCESS` and still has the `Flashduty` integration selected
* **The integration Test button**: the test names a real check and says `DOWN`, with `description` set to `test` and `long_description` starting with "This is a test message triggered by a user". Flashduty answers with success and creates no alert, so the check's real alerts are not affected
* **BeepManager webhooks**: this integration receives check state change webhooks. The legacy BeepManager alert format is not supported

See [Pingdom Webhooks](https://www.pingdom.com/resources/webhooks/) for the field definitions.