Skip to main content
Use a webhook recipient of CloudAMQP alarms to send instance alarms to Flashduty On-call. Each alarm subject (for example, one queue in one vhost) maps to one Flashduty alert: it is created when the alarm fires, reminders while the alarm stays active merge into the same alert, and the alert recovers when the alarm resolves.

​
In Flashduty On-call

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

​
Use a 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 CloudAMQP and click Save
  4. Open the generated integration card and copy the push URL

​
Use a shared integration

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

​
In CloudAMQP

1

Add a webhook recipient

  1. Sign in to the CloudAMQP console and open the instance you want to connect
  2. Go to Alarms and add a recipient of type Web hook
  3. Paste the full Flashduty push URL as the URL. The URL must include integration_key
2

Assign the recipient to alarms

CloudAMQP sends an alarm only to the recipients assigned to it. In Alarms, create or edit each alarm you want on-call to handle (queue, consumer, CPU, memory, disk, connection, server unreachable) and add the webhook recipient to its Recipients. Some alarm types are only available on dedicated instances; what the console offers is authoritative.To get repeated reminders, set a Reminder interval on the alarm (minimum 30 seconds). Each reminder pushes another event for the same alarm, and Flashduty merges it into the same alert.
3

Save and verify

  1. Click the Trigger button on the recipient. Flashduty creates an Info alert titled CloudAMQP test notification. It does not recover automatically, so close it by hand. The recipient’s Resolve button likewise only creates a separate Info test alert
  2. Fire a real alarm (for example, set a low message threshold on a queue and publish messages) and confirm Flashduty receives an active alert
  3. After the alarm resolves, confirm the alert recovers in Flashduty

​
Event types

CloudAMQP pushes one alarm subject per request, as JSON. CloudAMQP retries when the webhook returns a non-2xx status. Duplicate pushes carry the same Alert Key and merge into one alert.

​
Alert Key

Flashduty computes the Alert Key from dedup_key. It combines the alarm type and its subject (for a queue alarm, queue::<vhost>/<queue>), and the trigger, reminder, and resolve pushes of one subject carry the same value. Changes to the threshold, time threshold, current value, or subject text do not change the Alert Key. A request without dedup_key is rejected.

​
Status and severity

CloudAMQP pushes carry no severity, so every alarm type is Warning in Flashduty, and resolved: true recovers the alert. To distinguish severity, use a label such as alarm_type in the channel’s routing or alert processing rules.

​
Labels

​
Troubleshooting

  • Flashduty receives nothing: confirm the webhook recipient is added to the alarm’s Recipients, and check the recipient’s status column in the alarms list for errors
  • Invalid parameter error: confirm the URL is complete and includes integration_key
  • Alert does not recover: confirm the resolve push was delivered. CloudAMQP resets an alarm that has been active for 30 days, after which it may fire again; you can also enable auto-close on the channel as a fallback
  • Test alert stays open: the Trigger and Resolve button pushes never recover; close it by hand
For field details, see the CloudAMQP alarms documentation.