Skip to main content
Use the Webhook JSON type of a WhaTap 3rd party plugin to sync the event alerts of a project to Flashduty On-call. An alert is created when an event fires and is closed by the recovery notification (Resolved notification) of the same event.

In Flashduty On-call


You can get the push URL in either of two ways.

Dedicated integration

  1. In the Flashduty console, select Channels and open a channel
  2. Select Settings → Integrations → Dedicated Integrations, then click Add an Integration
  3. Select WhaTap and click Save
  4. Open the generated integration card and copy the Push URL

Shared integration

  1. In the Flashduty console, select Integration Center → Alert Events
  2. Select WhaTap and enter an integration name
  3. Configure the default route and pick a channel; you can add more rules under Routes after creating it
  4. Click Save and copy the generated Push URL

Configure in WhaTap


1

Add a Webhook JSON plugin

  1. Sign in to WhaTap, open the target project, go to Alert → Notifications, open the 3rd party plugin page and click Add
  2. Select the Webhook JSON tab
  3. Enter a display name in Webhook Name and the full Flashduty push URL (including integration_key) in Webhook URL. The page shows WhaTap’s default JSON template (15 fields). Keep it unchanged: Flashduty parses that default format. No custom header is needed
  4. To test, click Test alert. The test opens a separate Info alert in Flashduty; close it manually
  5. Click Registration to save
2

Enable event rules and keep the resolved notification on

Go to Alert → Event Configuration, edit the rule you want to forward, set the Critical, Warning or Info condition, keep Resolved notification on (it is on by default) and enable the rule. With the resolved notification off, Flashduty never receives the recovery and the alert does not close.
3

Verify the lifecycle

Push a metric past its threshold (for example, lower a CPU threshold temporarily) and confirm Flashduty receives an active alert; then restore the threshold and confirm the same alert recovers. The WhaTap history is under Alert → Event History.

Payload


WhaTap POSTs application/json; every value is a string. Flashduty parses it directly, no template is needed: Numeric values may carry thousands separators (for example 55,223.0). Flashduty keeps them as text labels and does not parse them.

Alert Key


The Alert Key is uuid. The fire and recovery notifications of one WhaTap event carry the same uuid, so they land on one Flashduty alert. When the level of the same object and rule changes (for example a Critical event recovers and a Warning event fires), WhaTap creates a new event with a new uuid, which is a separate alert in Flashduty. Changes to title, level, value or time do not change the Alert Key. A request without uuid is rejected with a parameter error, because its recovery could not be matched to the original alert.

Status and severity


Flashduty reads status first and level second, because a WhaTap recovery always carries level Info. A request whose status is neither on nor off is rejected, so a request of unknown state is never written into a wrong alert lifecycle.

FAQ


Not by default. WhaTap sends one notification when an event fires and one when it recovers, and nothing in between (the Recurring alert (escalation) setting on the Notifications page is 0, off, by default). If a delivery is repeated, the same uuid merges it into the same alert.
Refer to the current WhaTap plan description. 3rd party plugins are available during the trial.

Troubleshooting


  • The test created an Info alert: the notification sent by Test alert has no uuid. Flashduty recognizes it by all of its fixed content (oid 123456789, oname sample-name, title [Test] Alert reception test, message This is a test of WhaTap alert message, level Info, status on, and empty metric, okind and onode fields) and opens a separate Info alert that never recovers; close it manually. Any other request without uuid is still rejected
  • WhaTap reports a failed push: confirm the Webhook URL is the full push URL and includes integration_key
  • The alert does not recover: confirm Resolved notification is on for the rule and that the recovery goes through the same Webhook plugin