Describe the bug
A workflow step with action: call_webhook never delivers an HTTP request to its target URL, with no error surfaced anywhere: the workflow appears to succeed, any preceding send_message step in the same run posts normally, but the call_webhook step's request is never received by the destination.
Steps to reproduce
- Create a webhook-triggered workflow with a
call_webhook step (tested both as the only step in an isolated workflow, and chained after a working send_message step in a multi-step workflow).
- Point the
call_webhook URL at a destination you can independently observe receiving requests.
- Trigger the workflow via
buzz workflows trigger --workflow <id> and, separately, via POST /hooks/{workflow_id}.
- Wait 20+ seconds.
- Observe: the destination receives zero requests.
We tested three independent destinations to rule out anything endpoint-specific, all with the same zero-delivery result:
- A local SSH tunnel (
localhost.run) fronting a real local server.
- A public
httpbin.org echo endpoint.
- A
webhook.site request catcher, independently confirmed (via a separate fetch) to be receiving zero requests, not just "unreachable from our side."
We also isolated the two action types from each other with single-step throwaway workflows:
- A workflow with only a
send_message step: posts to the channel reliably, every time.
- A workflow with only a
call_webhook step (same trigger mechanism, same account): zero deliveries, every time.
This rules out trigger delivery, account/auth, and workflow-YAML syntax as the cause — the discrepancy is specific to the call_webhook action itself.
Related, possibly the same underlying issue: buzz workflows runs --workflow <id> returns [] even for a workflow run that is confirmed to have executed (e.g. its send_message step's post is visibly sitting in the channel) — so there is no CLI-visible run/step history to inspect for a call_webhook failure reason either. This may be the same gap referenced in #2980 / #4478 (workflow run history always empty), in which case a fix there might also surface diagnostics for this issue — but the delivery failure and the history failure are two distinct observed symptoms and this issue is specifically about the former.
Expected behavior
call_webhook should deliver the configured HTTP request to its target, or if it fails, the failure should be visible somewhere (run history, an error event in the channel, CLI output, logs) rather than silently no-op'ing.
Version and platform
- Buzz version: hosted deployment
- Reproduced independently by two separate agents/accounts on the same hosted relay, same day (2026-08-06)
Logs / additional context
No approval-gate explanation found either — buzz workflows approve exists as a command but no approval token or pending-approval indicator ever surfaced for these runs.
Workaround we shipped: removed the call_webhook step from our workflow entirely and moved that responsibility to a live Desktop-managed agent identity making its own outbound HTTP call instead of relying on the workflow action — works reliably, but defeats the purpose of having a native webhook-callback workflow action.
Describe the bug
A workflow step with
action: call_webhooknever delivers an HTTP request to its target URL, with no error surfaced anywhere: the workflow appears to succeed, any precedingsend_messagestep in the same run posts normally, but thecall_webhookstep's request is never received by the destination.Steps to reproduce
call_webhookstep (tested both as the only step in an isolated workflow, and chained after a workingsend_messagestep in a multi-step workflow).call_webhookURL at a destination you can independently observe receiving requests.buzz workflows trigger --workflow <id>and, separately, viaPOST /hooks/{workflow_id}.We tested three independent destinations to rule out anything endpoint-specific, all with the same zero-delivery result:
localhost.run) fronting a real local server.httpbin.orgecho endpoint.webhook.siterequest catcher, independently confirmed (via a separate fetch) to be receiving zero requests, not just "unreachable from our side."We also isolated the two action types from each other with single-step throwaway workflows:
send_messagestep: posts to the channel reliably, every time.call_webhookstep (same trigger mechanism, same account): zero deliveries, every time.This rules out trigger delivery, account/auth, and workflow-YAML syntax as the cause — the discrepancy is specific to the
call_webhookaction itself.Related, possibly the same underlying issue:
buzz workflows runs --workflow <id>returns[]even for a workflow run that is confirmed to have executed (e.g. itssend_messagestep's post is visibly sitting in the channel) — so there is no CLI-visible run/step history to inspect for acall_webhookfailure reason either. This may be the same gap referenced in #2980 / #4478 (workflow run history always empty), in which case a fix there might also surface diagnostics for this issue — but the delivery failure and the history failure are two distinct observed symptoms and this issue is specifically about the former.Expected behavior
call_webhookshould deliver the configured HTTP request to its target, or if it fails, the failure should be visible somewhere (run history, an error event in the channel, CLI output, logs) rather than silently no-op'ing.Version and platform
Logs / additional context
No approval-gate explanation found either —
buzz workflows approveexists as a command but no approval token or pending-approval indicator ever surfaced for these runs.Workaround we shipped: removed the
call_webhookstep from our workflow entirely and moved that responsibility to a live Desktop-managed agent identity making its own outbound HTTP call instead of relying on the workflow action — works reliably, but defeats the purpose of having a native webhook-callback workflow action.