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

In CloudAMQP

1

Add a webhook recipient in CloudAMQP

Where: CloudAMQP console › Monitoring › AlarmsOpen the instance you want to connect, then add a recipient under Alarms:
2

Assign the recipient to alarms

Where: CloudAMQP console › Monitoring › AlarmsCloudAMQP sends an alarm only to the recipients assigned to it. In Alarms, create (Add new) 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. Each reminder pushes another event for the same alarm, and Flashduty merges it into the same alert.
3

Save and verify

Where: CloudAMQP console › Monitoring › Alarms
  1. Click the Trigger button on the recipient. This only proves Flashduty can receive a push: 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. Recovery needs no separate setup: CloudAMQP pushes an event with resolved set to true when the alarm clears

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.