Before you start
You need a reachable destination and an instance that permits external HTTP. Store bearer tokens or Slack webhook URLs in Secrets. Use secret references in the workload instead of copying tokens into definitions. Start with a small Manual workload so you can check delivery without enabling a recurring schedule.1. Add a destination
In workload details, expand Callbacks and notifications and select Add destination. Give it a stable name, choose the channel, set its URL or secret reference, and select events. The complete Manual orders workload below includes this subscription in itsworkflow.notifications field:
kind: "slack"; its secret can hold the complete Slack webhook URL. The URL field must still contain a valid HTTP URL for definition validation.
A workload supports at most 16 uniquely named subscriptions. Each needs at least one event and 1–20 delivery attempts. Omitted max_attempts defaults to 5.
2. Choose events
The API event list is explicit. The editor exposes the main completion, task, sensor, and backfill events. Select only the events the receiver needs.
3. Run and check delivery
Start the workload, open its run, and select Notification history. Inspect the destination, event, delivery status, attempts, and any error. For a full event ID and delivery record, use GET/api/v1/workloads/{workload_id}/runs/{run_id}/notifications.
Check the event ID, subscription name, attempts, status, and last error. Delivery states are pending, in_flight, delivered, and exhausted. A successful run with an exhausted notification is still a successful run.
HTTP webhooks receive a JSON body with an event object. The request includes an Idempotency-Key header containing the event ID. Slack receives a text message identifying the event and workload/run or backfill.