Skip to main content
Use a Honeycomb webhook recipient to send Trigger alerts and SLO burn alerts to Flashduty On-call. Honeycomb identifies one alert firing by .Alert.InstanceID, and Flashduty uses it as the Alert Key: the notifications and the recovery of the same firing keep updating one Flashduty alert.

​
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 Honeycomb 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 Honeycomb and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Route after creation
  4. Click Save and copy the generated Push URL

​
Configure Honeycomb

These steps require a Honeycomb account that can edit integrations in Team Settings. Triggers are available on every plan; SLOs and burn alerts require the Pro or Enterprise plan.
1

Create a webhook recipient in Honeycomb and define the severity variable

Where: Honeycomb › Team Settings › Integrations › Trigger and SLO Recipients › Add IntegrationThen open the recipient’s Variables tab and click Add variable:Flashduty uses this variable to set the severity. Supported values are critical, warning, and info. When you select this recipient on a Trigger or burn alert later, you can override the default for that rule.
2

Configure the payload templates

Where: Honeycomb › Team Settings › Integrations › Trigger and SLO RecipientsOpen the Payload tab of the Flashduty recipient, click Enable for each of the three alert types, and paste the matching template. An alert type without an enabled payload cannot use this recipient.Triggers:
Budget Rate Burn Alerts:
Exhaustion Time Burn Alerts:
Then click Add.
Keep instance_id, status, and is_test. Flashduty rejects a request without instance_id, because it could not link the recovery to the original alert. status accepts only TRIGGERED and OK. Every string in the templates is written with toJson, so the rendered body stays valid JSON when a name or description contains quotes or line breaks.
3

Add the recipient to Triggers and SLO burn alerts

TriggerWhere: Honeycomb › Triggers › edit a Trigger or New Trigger › Recipients › Add RecipientContinuous alerts sends a notification on every evaluation while the condition holds and never sends a recovery, so you need to close the matching Flashduty alert manually.SLO burn alert (SLOs and burn alerts need the Pro or Enterprise plan)Where: Honeycomb › SLOs › Burn Alerts › Configure › New Burn AlertClick Create Burn Alert.
4

Verify the lifecycle

Where: Honeycomb › Triggers; Honeycomb › SLOs › Burn Alerts › ConfigureTest on a Trigger or burn alert sends test notifications with is_test set to true (a Limited alerts Trigger and a burn alert send one TRIGGERED and one OK; a Continuous alerts Trigger sends only TRIGGERED). Flashduty returns success for test notifications without creating an alert, so you can use them to check that the push URL is reachable.To verify the full flow, let the Trigger condition actually fire and confirm that Flashduty receives an active alert, then let the condition clear and confirm that the original alert recovers. A few seconds later the integration in Flashduty shows a Latest event time, which means setup works.

​
Alert key

Flashduty uses instance_id (.Alert.InstanceID) as the Alert Key. Honeycomb’s template variable reference defines it as the unique identifier of one Trigger or burn alert firing, useful for deduplicating and correlating alerts. Honeycomb’s official incident.io template also uses it as the deduplication_key and resolves the matching alert on OK.
  • Repeat notifications during one firing (for example, when a new group crosses a Trigger threshold) and the final recovery all update the same Flashduty alert
  • When the same Trigger or burn alert fires again after recovering, it gets a new InstanceID and becomes a new Flashduty alert
  • Changes to the name, description, severity, or environment do not change the Alert Key
With Group resolution alerts, Flashduty also merges notifications by instance_id and recovers the alert when a notification with status OK arrives. The alert description lists the groups currently over the threshold.

​
Status and severity

Flashduty uses status to tell triggers from recoveries, and the severity variable to set the severity. When status is OK, Flashduty recovers the original alert and keeps its last severity. An empty or any other status is rejected.

​
Labels

​
Troubleshooting

  • The Flashduty recipient is not selectable in Honeycomb: Confirm that the matching alert type is enabled on the Payload tab and has a template
  • Flashduty returns a parameter error: Confirm that the template matches the one above and that instance_id and status are not empty. Honeycomb does not retry 4xx responses
  • Every alert is Critical: Confirm that the severity variable is defined and overridden on the Trigger or burn alert where needed
  • Alerts do not recover: Confirm that the Trigger does not use Continuous alerts. Test notifications neither create nor recover alerts
For more information, see the Honeycomb documentation: Send Alerts to Webhooks, Custom Webhook Variables, and Monitor SLOs.