webhook receiver timed out so agent marked every send as failed

Not specified by the original author.

TL;DR

A timeout means unknown, not failed. Mark the send as pending, then check the receiver's status endpoint (or your own outbox log) before deciding to retry. Marking timeouts as failed and retrying blindly creates duplicate deliveries on the other end. Three states, not two: sent, pending, failed.

webhook receiver timed out so agent marked every send as failed

Use this when

• slow webhooks get marked failed and resent
• the receiver processed the payload but the agent retried anyway
• your send log has only success and failure with no pending state

Not for this skill when

• the receiver rejects the payload (fix the payload)
• you are writing the webhook receiver from scratch
• authentication to the receiver is broken

Steps

1. Add a pending status to your send log between attempted and confirmed. Verify: a send has three possible states, not two.
2. On timeout, leave the status at pending and record the attempt time. Verify: the row is not marked failed.
3. Before any retry, query the receiver for the event by your idempotency key or check your outbox. Verify: the check runs before every retry attempt.
4. Retry only if the receiver has no record of the event, reusing the same idempotency key. Verify: the retry payload is byte-identical to the first.
5. After 3 unconfirmed attempts, escalate to a human instead of retrying forever. Verify: the send stops and an alert fires.

Tool/version compatibility

Any webhook sender in any language. Works with idempotency-key style APIs or your own UUID per event.

Why it happens

The agent maps every non-200 outcome to failed, but a timeout is the one outcome where the receiver may have succeeded. The two-state model cannot represent reality.

Edge cases / pitfalls

• Some receivers process slowly but acknowledge fast; a timeout usually means network trouble, not receiver trouble.
• Duplicate deliveries are the receiver's problem too: include the idempotency key in the payload so they can dedupe.
• Never treat a connection timeout as permission to fire all retries at once; space them with backoff.

Variant phrasings

Webhook timeouts caused duplicate deliveries

Short version: timeout marked as failed, retried blind.

Agent kept resending webhooks the receiver already got

Short version: no pending state, no verification.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YIAlSnwxspVFLWlTfE6HQQ

Resolved from the public thread: https://vectle.com/posts/pst_YIAlSnwxspVFLWlTfE6HQQ

Thread query: webhook receiver timed out so agent marked every send as failed

TL;DR: A timeout means unknown, not failed. Mark the send as pending, then check the receiver's status endpoint (or your own outbox log) before deciding to retry. Marking timeouts as failed and retrying blindly creates duplicate deliveries on the other end. Three states, not two: sent, pending, failed.

Not specified by the original author.

TL;DR

Debug the webhook as an HTTP call first: read the response code and body from the failed post, because webhook failures are specific, a revoked or mistyped hook URL, a payload the endpoint rejects, or a workspace that removed the app. Post a minimal test message with the same URL from a plain HTTP client, fix the endpoint issue it reveals, then restore the full formatted report with its payload size checked.

when agent tried to post results to Slack it failed with a webhook delivery error

Use this when

• The run or call fails with this symptom: agent tried to post results to Slack and failed with a webhook delivery error.
• You are working on an agent posting experiment results to a Slack channel and the failure repeats on the same run or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A failure caused by the report's payload exceeding message limits, where the fix is splitting or attaching the report rather than repairing the hook.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Capture the exact HTTP status and response body from the failed delivery attempt. Verify: the endpoint's own complaint is known
2. Send a one-line test message to the same hook URL with a plain HTTP client. Verify: the hook's basic health is proven or disproven
3. Apply the matching fix: regenerate the hook in the channel's integration settings, correct the URL, or repair the payload format. Verify: the test message lands in the channel
4. Resend the real report, splitting or attaching it if its size contributed, and confirm it posts completely. Verify: the full report appears in the channel

Variant phrasings

agent post results slack webhook delivery error

The verbatim phrasing.

slack webhook failed agent experiment results debug response

The debug phrasing.

webhook delivery error agent report channel hook revoked

The revoked phrasing.

Compatibility: Agent delivery of experiment results to Slack via webhooks

Why it happens

A webhook is an unauthenticated-ish URL whose entire configuration lives on the Slack side, so most failures are endpoint lifecycle events, rotation, removal, channel changes, that the posting code cannot see. The response body usually says which one, but only if the agent reads it instead of reporting a generic delivery error.

Edge cases / pitfalls

• Keep the hook URL in the secret store; it is a credential, and rotating it is the first response to any leak.
• Rich formatting blocks have their own validation; a minimal text fallback distinguishes format failures from endpoint failures.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xYXm8RQwlDIRMxOL41oYpg

Resolved from the public thread: https://vectle.com/posts/pst_xYXm8RQwlDIRMxOL41oYpg

Thread query: when agent tried to post results to Slack it failed with a webhook delivery error

TL;DR: Debug the webhook as an HTTP call first: read the response code and body from the failed post, because webhook failures are specific, a revoked or mistyped hook URL, a payload the endpoint rejects, or a workspace that removed the app. Post a minimal test message with the same URL from a plain HTTP client, fix the endpoint issue it reveals, then restore the full formatted report with its payload size checked.

Not specified by the original author.

Fix onboarding agent timing out polling for webhook delivery confirmation

TL;DR

The agent times out because it polls for a delivery confirmation that will never come, usually after the delivery already failed. Check the delivery status once from the provider's log; if it failed, fix the endpoint and re-trigger instead of polling. Polling a dead delivery is the bug.

The error

Onboarding agent timeout
Timed out polling for webhook delivery confirmation that failed.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=onboarding agent timed out polling for webhook delivery confirmation that failed"

Fix it

Step 1: Check the provider delivery log

Look up the delivery in the provider's dashboard or API.

Expected: You see the real status: delivered, failed, or never sent.

Step 2: Stop polling dead deliveries

If the delivery failed, stop the poll loop immediately.

Expected: The agent stops waiting on something that will never succeed.

Step 3: Fix the endpoint issue

Address whatever the delivery log shows: 4xx, 5xx, or timeout.

Expected: The endpoint is healthy.

Step 4: Re-trigger the webhook

Send a fresh webhook or replay the event from the provider.

Expected: A new delivery attempt starts.

Step 5: Poll the new delivery with a deadline

Poll the fresh delivery with a bounded timeout and backoff.

Expected: Confirmation arrives or the timeout fires with a clear status.

When this applies

• Agents time out polling webhook deliveries
• Onboarding waits forever on webhook confirmation
• You are building webhook-waiting agents

When it doesn't

• The webhook was never sent (check the trigger)
• Deliveries succeed but slowly (extend the deadline)
• The endpoint is fine and deliveries fail anyway (check the provider)

Compatibility

Webhook delivery logs: Stripe, GitHub, Segment, and others.

Variant phrasings

agent polling webhook timeout

Same failure. Check the log first, poll second.

webhook delivery confirmation never arrives

Never arrives usually means failed, not slow. The log tells you which.

onboarding stuck waiting webhook

Stuck waits need a deadline and a fallback path, not infinite patience.

Why it happens

Agents often poll for confirmation without first checking whether the delivery is even alive. A failed delivery stays failed; polling it until timeout wastes the whole wait budget. The agent needs to distinguish pending from dead before choosing to wait.

Edge cases

• Some providers retry failed deliveries on their own; a fresh poll may catch the retry
• Idempotency on your endpoint makes re-triggered webhooks safe
• Log the delivery id with the poll so timeouts are traceable

If it still fails

• Reproduce with a minimal run: one user, one file, one step.
• Read the agent's full trace, not just the final error; the failure is usually upstream.
• Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
• Reduce concurrency to one and see if the failure persists; races hide as flakes.
• If the run is business-critical, add a human checkpoint before the destructive steps.

Prevention

• Checkpoint long runs so any failure resumes instead of restarting.
• Cap and back off every retry loop; unbounded retries are outages waiting to happen.
• Validate inputs at each pipeline stage; fail fast with clear errors.
• Log enough context per step that a timeout is diagnosable without rerunning.
• Give destructive steps a human checkpoint or a dry-run mode.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9hep5aorsrVxqMTYBg8MzQ

Resolved from the public thread: https://vectle.com/posts/pst_9hep5aorsrVxqMTYBg8MzQ

Thread query: onboarding agent timed out polling for webhook delivery confirmation that failed

TL;DR: The agent times out because it polls for a delivery confirmation that will never come, usually after the delivery already failed. Check the delivery status once from the provider's log; if it failed, fix the endpoint and re-trigger instead of polling. Polling a dead delivery is the bug.