Skip to main content
Thinkst Canary provides honeypot devices and Canarytokens. When someone touches a decoy device or triggers a token, the Canary Console posts a JSON body to your generic webhook. Each incident becomes one Flashduty alert. Canary sends nothing when an incident is acknowledged or closed, so alerts do not recover on their own and you should enable auto-close.

​
In Flashduty On-call

Get the push URL in either of these ways.

​
Use a dedicated integration

  1. In the Flashduty console, choose Channels and open a channel
  2. Choose Settings → Integration data → Dedicated integrations, then click Add an integration
  3. Select Thinkst Canary and click Save
  4. Open the integration card and copy the push URL

​
Use a shared integration

  1. In the Flashduty console, choose Integration Center → Alert events
  2. Select Thinkst Canary and enter a name
  3. Configure the default route and pick a channel; you can add more rules under Routes later
  4. Click Save and copy the push URL

​
Configure Thinkst Canary

1

Add a generic webhook

In the Canary Console, add a generic webhook under Console Settings → Notification Channels (or Webhooks in Flock Settings). Use the full push URL, including ?integration_key=....
2

Verify connectivity

When you save the webhook, the console posts a fixed test incident (canary name DummyDevice, intro This is a dummy incident.). Flashduty recognises it, returns 200, and creates a separate Info alert titled Thinkst Canary test notification. It never merges into a real incident; close it manually.
3

(Optional) Send audit events

The console can also post audit-trail events ({"type":"console-audit"}, such as user logins or Canarytoken creation) to the same URL. Flashduty returns 200 and ignores them; they do not create alerts.

​
Alert Key

Flashduty uses the incident’s IncidentHash as the Alert Key. Canary device incidents and Canarytoken incidents both carry it, and deliveries with the same hash merge into one alert. A request without IncidentHash is rejected, except the test incident.

​
Alert lifecycle

Canary only sends the incident itself; there is no recovery message. Enable auto-close on the channel, start the timer from Incident triggered, and use 24 hours as a starting point, adjusted to your response process.

​
Severity

Canary messages have no severity field. AlertType CanaryIncident (device) or CanarytokenIncident (token) maps to Critical, because any touch of a decoy is an intrusion signal. Any other value maps to Warning. To change this, rewrite severity with an alert processing rule on the alert_type or log_type label.

​
Alert content

  • Title: incident type (Description)
  • Description: incident summary (Intro)
  • Labels: check, resource (canary name, or the token’s Reminder note), incident_hash, alert_type, log_type, canary_name, canary_id, canary_ip, canary_port, canary_location, source_ip (who touched the decoy), reverse_dns, and source (always thinkst_canary)
AdditionalDetails (request details that may include usernames) and the Canarytoken value are not written to the alert.

​
About signatures

The Canary generic webhook documentation does not describe request signing. Flashduty identifies the integration by the integration_key in the push URL.

​
Troubleshooting

  • No alerts arrive: confirm the webhook URL is the full push URL, the integration is enabled, and the console can reach a public address
  • Only an Info alert appears: that is the test incident sent when saving the webhook; real incidents arrive when a device or token is triggered
  • Alerts never close: Canary sends no recovery message, so enable auto-close
For the full field reference, see Canary’s Generic Webhook events.