## 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.

```text
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