Skip to main content
Use a Checkly Webhook Alert Channel to send check-state changes to Flashduty On-call. Failure, degradation, continued failure, and recovery notifications for one Check update the same Flashduty alert.

​
In Flashduty On-call

Create either a dedicated or shared Checkly alert integration and copy its complete Push URL.

​
Configure Checkly

1

Create a Webhook Alert Channel in Checkly

Where: Checkly › Alert Settings › Add more channels › WebhookUse this Body template and keep alert_type and check_id. Do not put API keys, tokens, passwords, cookies, or other secrets in the payload:
2

Choose notifications and subscriptions in Checkly

Where: Checkly › Alert SettingsOpen the Webhook channel you created in the previous step and set Notification events.Recovery must be enabled. Otherwise, a recovered Check cannot recover its existing Flashduty alert.
3

Verify with a real lifecycle

Where: Checkly › Alert SettingsCheckly’s test send or an HTTP 200 from the webhook only proves the URL is reachable (Flashduty does not recognize test messages and handles them as a normal alert; close it manually); it does not prove Alert Key correlation or recovery. Move a subscribed Check through failure, degradation, and recovery, and confirm that the same Flashduty alert triggers, updates, and recovers.

​
Alert key

Normal check-state notifications use the trimmed check_id (Checkly variable CHECK_ID) as the Alert Key. Titles, errors, run locations, response times, result IDs, and alert-state changes do not affect it.
If check_id is missing or empty, Flashduty accepts the request and generates a random UUID for that notification. These notifications cannot correlate: a later update or recovery without check_id cannot find the earlier alert.
ALERT_SSL is an independent one-shot Warning event. It always receives a new random UUID, even when the payload includes check_id, and does not update or recover the Check’s normal state alert.

​
Status and severity

An empty or unknown alert_type returns an invalid-parameter response. Recovery is determined only by alert_type, not by the title or error text.

​
Labels and description

Flashduty creates these labels:
  • check and source=checkly
  • check_id and checkly_alert_type
  • check_name, check_type, and group_name
  • region and run_location
  • is_reminder and reminder_sequence
  • JSON-encoded tags
check_result_id is a high-cardinality per-run value and is not stored as a label. The bounded alert description contains the error, response status, response time, start time, and result link.

​
Size and count limits

The request body, labels, and description all have hard limits, handled as follows: A label value that is empty after trimming is not written to the alert.

​
Delivery and troubleshooting

Checkly retries a failed webhook delivery up to five times at approximately 20-second intervals. Use Checkly’s Alert Notification Log to inspect the final delivery result.
  • Flashduty returns an invalid-parameter error: verify that Body is valid JSON, matches the complete template, and contains a supported alert_type
  • One Check creates multiple alerts: confirm that every notification carries the same non-empty check_id
  • The alert does not recover: enable Recovery and confirm that the recovery payload has the same check_id as the trigger
  • No degradation alert arrives: enable Degradation and configure a degradation condition on the Check
  • No notification arrives: confirm that the Check or Check Group subscribes to this Webhook Channel, then inspect the Alert Notification Log
See Alerting With Checkly for Checkly’s state-transition model.