feat: generic webhook actionner

[ntcdeveloper]

Summary

Add a generic webhook actionner to falco-talon that POSTs a Falco event to an external HTTP endpoint and handles the response. This enables integrating any HTTP-based tool (RCA engines, enrichment services, custom automation) into the talon action chain without needing a dedicated actionner per tool.

Motivation

Tools like Wachd receive a Falco event, run AI-powered root cause analysis, and return a plain-English explanation of why the event happened. With a generic webhook actionner, talon can call Wachd (or any similar tool), wait for the result, and include it in the notifier payload — so the on-call engineer gets the automated response and the root cause in one notification.

Proposed behaviour

The actionner POSTs the Falco event payload to a configured URL. Several response strategies should be supported to accommodate tools with different latency profiles:

• Sync wait — wait for the HTTP response inline (with configurable timeout)
• WebSocket — keep the connection open and receive the result when ready (with timeout)
• Poll foreground — POST returns a job ID; talon polls a status endpoint until complete (configurable interval + max attempts), blocking the action chain
• Poll background — same as foreground but polling runs async, unblocking the rest of the chain

Suggested configuration

- action: Webhook RCA
  actionner: webhook:generic
  parameters:
    url: https://wachd.company.internal/api/v1/webhook/<teamId>/<secret>
    method: POST
    timeout: 60
    response_mode: poll          # sync | websocket | poll
    poll_endpoint: https://wachd.company.internal/api/v1/teams/<teamId>/incidents/{id}
    poll_interval: 5
    poll_max_attempts: 12
    headers:
      Content-Type: application/json

Notes

• Discussed in CNCF Slack #falco thread (2026-06-08) with @thomaslabarussias
• The poll modes (foreground/background) are particularly useful for AI-backed tools where processing time varies with backend and model
• Happy to help test against Wachd's incident endpoint or share the response format for speccing the poll contract

[ntcdeveloper]

/kind feature

[Issif]

Hello,

This is very good idea, thank you, I've some other comments.

I think it should be a group of actionners webhook, with different actionners:

• basic
• websocket
• poll

They will all share some settings and have specific ones.
For example webhook:poll could have background: true|false

The system is not ready yet for managing any action the background.

Moreover, a webhook means a response, we have to specify what do to with. Allowing to use an output for example, but also, if it's a json, we could imaging being able to specify a jsonpath or equivalent to extract a part, and pass it the next step (or output).

[ntcdeveloper]

Thanks @Issif — the grouping makes more sense, agreed on webhook:basic, webhook:websocket, webhook:poll.

For the poll contract, here's what Wachd actually returns so it's concrete to spec against:

Step 1 — initial POST to the webhook endpoint

POST /api/v1/webhook/{teamId}/{secret}

Response (202 Accepted):

{ "status": "created", "incident_id": "550e8400-e29b-41d4-a716-446655440000" }

$.incident_id is what Talon would carry forward to the poll step.

Step 2 — poll the incident endpoint

GET /api/v1/teams/{teamId}/incidents/{incident_id}

While the worker is processing, analysis is absent. Once it finishes:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "status": "open",
  "severity": "critical",
  "title": "CPU spike on payments-api",
  "analysis": {
    "root_cause": "A deployment 8 minutes before the alert introduced a missing DB index. Query times spiked from 12ms to 4.2s under normal load.",
    "suggested_action": "Roll back deployment a3f9c12 or add the missing index manually.",
    "confidence": "high",
    "key_findings": [
      "Deployment a3f9c12 pushed 8 minutes before alert",
      "Error rate on /checkout jumped from 0.1% to 34%",
      "DB query p99 increased 350x"
    ],
    "is_deployment_cause": true
  },
  "fired_at": "2026-06-12T07:00:00Z",
  "created_at": "2026-06-12T07:00:01Z",
  "updated_at": "2026-06-12T07:01:23Z"
}

Done condition: $.analysis != null
Result to pass to notifier: $.analysis.root_cause

The background: true mode on webhook:poll makes a lot of sense here — Wachd processing takes 5–60s depending on the AI backend (cloud vs local Ollama), so blocking the chain isn't always what you want.

Happy to test against a branch or share more of the response contract if useful.