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

  1. In Checkly, open Alert Settings
  2. Click Add more channels and select Webhook
  3. Enter Flashduty as the name
  4. Select POST as the method
  5. Paste the complete Flashduty integration Push URL into URL
  6. Add Content-Type: application/json under Headers
2

Choose notifications and subscriptions

  1. Enable Failure, Degradation, and Recovery under Notification events
  2. Optionally enable SSL certificate expirations
  3. Subscribe the Checks or Check Groups that should send notifications to Flashduty
Recovery must be enabled. Otherwise, a recovered Check cannot recover its existing Flashduty alert.
3

Configure the payload

Replace Body with this complete JSON template:
Keep alert_type and check_id. Never add API keys, tokens, passwords, cookies, or other secrets to the payload.
4

Verify a real lifecycle

Move one subscribed Check through failure, degradation, and recovery. Confirm that one Flashduty alert is triggered, updated, and recovered.A Checkly test notification or webhook HTTP 200 proves connectivity only. Use real Check state changes to verify Alert Key correlation and recovery.

​
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.

​
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.