Skip to main content
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.

​
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

​
Configure Pingdom

1

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

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

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.
When the SolarWinds APM Integrated Experience is enabled, Pingdom menus may be in different places. Look for Integrations and the check’s alerting settings.

​
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

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: 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 for the field definitions.