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 integration
  3. Select Pingdom and click Save
  4. Open the generated integration card and copy the Push URL

​
Use a shared integration

  1. In the Flashduty console, go to 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 Routing after creation
  4. Click Save and copy the generated Push URL

​
Configure Pingdom

1

Create a webhook integration in Pingdom

Where: My Pingdom › Settings › Integrations › Add integrationThen click Save integration.After saving, you can click Test next to the integration. The test is a DOWN for a check with description set to test. It only proves that Pingdom can reach the push URL: Flashduty answers with success and creates no alert.
2

Enable the integration on your checks

Pingdom sends a webhook only when a check changes state, once for the failure and once for the recovery. There is no separate recovery switch: as long as the check has the integration selected, the recovery is sent.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

Where: My Pingdom › Synthetics › UptimeMake 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. The integration’s Test only verifies connectivity and does not replace this step.
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.