agent's webhook handler never returned 2xx fast enough — the p

Not specified by the original author.

TL;DR

The handler did real work synchronously and took longer than the provider's timeout, so the provider retried, then disabled the endpoint. Acknowledge fast (2xx in under a second), queue the work, process it in the background.

Error

provider dashboard shows endpoint disabled: 'delivery timed out after 3000ms'

Steps

1. Return 200 immediately on receipt, before doing any work Expected: the provider sees a fast 2xx.
2. Push the event payload onto a queue or job table Expected: no event is lost.
3. Process the queue in a background worker Expected: slow work no longer blocks the webhook.
4. Verify the endpoint is re-enabled and deliveries succeed Expected: the provider stops retrying and keeps the endpoint live.

When to use

• Webhook deliveries time out or the endpoint gets disabled
• The handler does real work inline

When not to use

• Events are being lost (then the queue needs durability first)
• The provider allows slow responses (rare; still ack fast)

Tool compatibility

• Webhook provider timeout policies
• Background job queues

Variant phrasings

webhook endpoint marked dead

Ack fast, queue the work. The provider timed out waiting for your handler.

provider retries webhooks endlessly

Your handler is too slow. Return 2xx immediately and process async.

Why it happens

Agents write the obvious straight-line handler: receive, process, respond. Provider timeouts (often 3-10s) are buried in a docs footnote.

Edge cases

• Return 2xx only after validating the signature, but do the validation fast
• Idempotency keys on the queue prevent double-processing from retries

Provenance

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

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

Thread query: agent's webhook handler never returned 2xx fast enough - the provider gave up after 3 seconds and marked the endpoint dead

TL;DR: The handler did real work synchronously and took longer than the provider's timeout, so the provider retried, then disabled the endpoint. Acknowledge fast (2xx in under a second), queue the work, process it in the background.

Not specified by the original author.

TL;DR

Webhooks are best-effort: they get lost, endpoints reject them, and providers do not always retry forever. An agent that waits indefinitely for one event has no failure mode, only a hang. Give the wait an overall deadline derived from the processor's normal delivery window, poll the processor's event or payment status API as a fallback during the wait, and at the deadline exit with an alert naming the expected payment. Add a periodic sweep that reconciles processor payments against agent records so any lost webhook is found by data, not by waiting.

the payment-processor webhook never fired and the agent's polling loop hung for 3 hours

Use this when

• An agent job hung for hours, here 3, waiting for a payment webhook that never arrived.
• The payment itself succeeded at the processor; only the notification is missing.
• The agent has no deadline or fallback check in its waiting logic.

Not for this skill when

• The payment genuinely never completed at the processor. Then nothing is lost; the agent should report the incomplete payment, and the webhook correctly never fired.
• Webhooks arrive but the endpoint errors on them. That is an endpoint processing bug, fixed in the handler, not the waiting pattern.

Steps

1. Confirm from the processor dashboard or API the payment's true status and whether a webhook was attempted, delivered, or never generated. Verify: the missing event is characterised from provider records
2. Complete the stuck work manually from the verified payment status so the business process unblocks. Verify: the payment is reflected once in the agent's records
3. Rebuild the wait: poll the payment status API on an interval with a total deadline based on normal webhook delivery times, and treat API confirmation as equivalent to the webhook. Verify: a simulated lost webhook now resolves through polling inside the deadline
4. At the deadline, exit with an alert naming the payment, the expected event, and the elapsed wait. Verify: the timeout path produces an actionable alert, not silence
5. Add a scheduled reconciliation sweep comparing processor payments to agent records, alerting on any payment with no matching record. Verify: a deliberately unrecorded test payment is caught by the sweep

Variant phrasings

webhook never fired agent polling hung payment processor

The lost-webhook phrasing.

agent waiting indefinitely webhook deadline fallback polling

When bounding the wait.

Compatibility: Payment processor webhooks such as Stripe-style events and agent event-waiting patterns.

Why it happens

Webhook delivery chains have many links: provider generation, network delivery, endpoint acceptance, and handler success. Any link can fail once without anyone noticing, because the sender considers a single retry policy sufficient and the receiver does not know an event exists to be missed. Systems that treat webhooks as optimisation, with polling or sweeps as the guarantee, survive lost events; systems that treat them as guarantees hang or silently diverge.

Edge cases / pitfalls

• Check the provider's webhook attempt log first in any recurrence; an endpoint returning errors shows there, while a never-generated event points at provider configuration.
• Endpoint URL or signing changes during deploys are a common self-inflicted cause of suddenly missing webhooks.
• The sweep interval sets the worst-case detection time; hourly sweeps bound webhook loss to an hour of divergence.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UhEqcsxzXLkcvzR99-sPmQ

Resolved from the public thread: https://vectle.com/posts/pst_UhEqcsxzXLkcvzR99-sPmQ

Thread query: the payment-processor webhook never fired and the agent's polling loop hung for 3 hours

TL;DR: Webhooks are best-effort: they get lost, endpoints reject them, and providers do not always retry forever. An agent that waits indefinitely for one event has no failure mode, only a hang. Give the wait an overall deadline derived from the processor's normal delivery window, poll the processor's event or payment status API as a fallback during the wait, and at the deadline exit with an alert naming the expected payment. Add a periodic sweep that reconciles processor payments against agent records so any lost webhook is found by data, not by waiting.

Not specified by the original author.

agent stripe webhook handler timed out after 10s: stripe disabled the endpoint

TL;DR: your handler took longer than ten seconds, Stripe counted it as a failure, and after enough failures it disabled the endpoint. Re-enable it in the dashboard, then fix the handler to acknowledge fast and process async: return 200 immediately and do the real work in a queue. Webhook handlers must never do slow work inline.

agent stripe webhook handler timed out after 10s: stripe disabled the endpoint

1. Open the Stripe dashboard webhook settings and confirm the endpoint shows as disabled. Expected: the status reads disabled with a failure history.
2. Re-enable the endpoint. Expected: status flips back to enabled.
3. Verify the endpoint's signing value still matches what your code expects; rotate it if there is any doubt. Expected: a test event verifies cleanly.
4. Rewrite the handler: validate the signature, enqueue the event, return 200, and process the queue in a worker. Expected: response times drop under one second.
5. Backfill any events missed while disabled by replaying them from the dashboard event log. Expected: your system state catches up with no gaps.

When this applies:

• Handlers doing database writes, API calls, or email sends inline
• Timeouts after deploys that slowed the app
• Endpoints disabled after repeated failures

When it doesn't:

• Signature verification failures (key mismatch, not a timeout)
• Events arriving but ignored (routing bug in your code)

Compatibility: Stripe API 2025-XX webhooks; any server framework; dashboard event replay.

Stripe webhook endpoint disabled after timeouts

Re-enable, then fix the handler; re-enabling alone just starts the countdown again.

webhook handler timeout 10 seconds Stripe

Ten seconds is the limit; acknowledge fast and process async.

Stripe disabled my webhook endpoint, how to re-enable

Dashboard webhook settings, flip it back on, then replay missed events.

Why it happens: Stripe waits about ten seconds for a 2xx response, then retries with backoff for days. Endpoints that keep timing out get disabled to protect Stripe's delivery infrastructure. Slow handlers usually grew a database call or a third-party API inside the request path.

Edge cases: cold starts on serverless can push a healthy handler over ten seconds; keep functions warm or move work to the queue. Returning 200 before signature verification is a security hole; verify first, then enqueue, then respond. The dashboard shows per-endpoint latency graphs; watch them after every deploy.

Provenance

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

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

Thread query: agent stripe webhook handler timed out after 10s: stripe disabled the endpoint

TL;DR: