Skip to main content
Use the Falcosidekick webhook output (or Falco’s built-in http_output) to send runtime security events matched by Falco rules to Flashduty On-call. Each Falco event maps to one Flashduty alert. Falco is an event stream and never sends a recovery message after a rule fires, so these alerts do not recover on their own. Turn on the channel’s auto-resolve timeout as described below.

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 Channels and open a channel
  2. Select Settings → Integrations → Dedicated integrations, then click Add integration
  3. Select Falco, then 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 Falco and enter an integration name
  3. Configure the default route and pick a channel; you can add more rules under Routes after creating it
  4. Click Save and copy the generated Push URL

Configure Falco

Pushing through Falcosidekick is recommended, because minimumpriority filters low-priority events at the source. If you do not run Falcosidekick, Falco can push directly.
1

Configure the webhook output in Falcosidekick or Falco

The push URL contains integration_key. Paste it in full and keep the parameters after the question mark.
2

Verify

Where: terminal on the Falcosidekick hostSend a request to Falcosidekick’s /test endpoint (listening on port 2801 by default):
Flashduty creates a new alert titled Test rule with Info severity. The test alert uses its own Alert Key, is never merged into a real alert and does not auto-recover, so close it manually once you see it. /test only proves the Falcosidekick-to-Flashduty path; it does not go through Falco rules. With direct push there is no such endpoint, so verify with a real rule.Then trigger a real rule on a monitored host or container (for example, open an interactive shell in a container to trigger Terminal shell in container) and confirm the matching alert appears in Flashduty.

Alert key

Each Falco event is an independent detection with no lifecycle, so each event becomes its own alert:
  • Through Falcosidekick, the Alert Key is the event uuid. Falcosidekick generates a new uuid for every event, so a redelivered event does not create a duplicate alert.
  • Falco’s direct JSON carries no uuid. The Alert Key is then an MD5 of rule, hostname, source, time, and output.
A request without rule is rejected, because Flashduty cannot tell which rule fired.

Status and severity

Labels

The title is the rule name (rule) and the description is output. These fields become labels: rule, priority, hostname (also used as resource), falco_source, falco_uuid, and tags (comma-separated). Every field in output_fields also becomes a label, with . in the key replaced by _, for example container.id becomes container_id and k8s.pod.name becomes k8s_pod_name. At most 50 labels are kept.

Recovery

Falco sends no recovery event, so alerts do not resolve on their own. Turn on the auto-resolve timeout for the channel that receives Falco alerts (24 hours suggested; adjust it to how quickly you need to respond), or close alerts by hand after handling them.

Troubleshooting

  • Falcosidekick logs a webhook error: check that the address is complete, includes integration_key, and that api.flashcat.cloud is reachable from where Falcosidekick runs
  • Flashduty returns a parameter error: make sure Falco has json_output: true and the body is valid JSON containing rule
  • No alert arrives: confirm the rule actually fired (check Falco’s own log first) and that minimumpriority is not filtering it out
  • Too many alerts: tune the rules in Falco or raise minimumpriority; repeated alerts from one rule can be merged with the channel’s noise reduction settings
For more details, see Falco output channels and the Falcosidekick webhook output.