TL;DR: Stop waiting on the webhook alone and poll the scanner's scan-status API with a deadline. Webhooks get lost to rotated receiver URLs, signature-verification failures, or proxy blocks, and the agent cannot tell "scan still running" apart from "event lost". A poller with a timeout converts a silent 6-hour stall into a bounded wait plus an alert.

```text
agent log: waiting for scan-complete webhook (6h elapsed) - scanner shows scan finished 5h ago
```

1. Look up the scan in the scanner UI or API and confirm it completed and when. Expected: you confirm the scan finished, so the missing piece is delivery, not the scan itself.
2. Check the webhook receiver logs for rejected deliveries around the completion time. Expected: you find a signature failure, a 404 on the endpoint, or nothing at all (the event was never sent).
3. Verify the registered webhook URL is still correct and reachable from the scanner's network - most scanners have a test-delivery button in the webhook settings. Expected: a test delivery returns 200.
4. Add a poller: every 5 minutes query the scan-status API, and proceed when the status reads complete or a 30-minute deadline passes. Expected: the agent advances on the next poll even if the webhook never arrives.
5. Keep the webhook as the fast path but make event handling idempotent. Expected: a late duplicate delivery does not re-trigger triage.

## Use this when
- the agent waits on scan-complete webhooks that never arrive
- scans finish but the agent never wakes up
- the webhook receiver shows delivery gaps
- pipeline stalls with no error, just silence

## Not for this skill when
- the scan itself never finishes (a scanner performance problem)
- the webhook arrives but the payload fails to parse (a parser problem)
- you control neither the scanner nor the receiver
- the event is delayed minutes, not lost for hours

## Variant phrasings
- scanner webhook not delivered to agent
- agent stuck waiting for scan event
- webhook lost, triage pipeline stalled
- scan-complete event never received

## Why it happens
Webhooks are fire-and-forget: endpoint URL rotations, expired signing secrets, proxy or firewall changes, and receiver restarts during delivery all drop events silently. The agent's wait has no deadline, so a lost event looks identical to a slow scan - until someone notices the idle hours.

## Edge cases
- scanners often retry webhooks with backoff, so the poller must be idempotent against a late webhook arriving after the poll already advanced the pipeline
- clock skew between scanner and agent shifts "completed at" comparisons - compare statuses, not timestamps
- some scanners only send webhooks for scheduled scans, not manual or API-triggered ones - the poller covers both
- a deadline that is too short pages on genuinely long scans - base it on the 99th percentile scan duration

## Provenance

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