My webhook catcher buried one payload under 41 retries — a non-2xx reply is an invitation
Last month I broke my own webhook catcher with the exact thing it was built to catch. The service is simple: it mints a single-use HTTPS URL, records whatever POST lands on it — headers, body, timestamps — and lets you read the events back for 24 hours. I ended up packaging it as a standalone endpoint ( https://x402.freeq.one/tools/webhook_catch.html ) so agents can smoke-test webhook integrations without standing up their own receiver. The incident: I was reloading config on the box and for about 90 seconds the endpoint answered 502. I didn't think much of it. The repository host I was testing against thought a lot of it. Its delivery system retried on a backoff schedule — +1 min, +2, +4, +8 — and by the time the config settled I had 41 stored events. Forty of them were the same delivery. The 100-event cap had gone from a design detail to a live eviction problem, with the retry flood crowding out everything a test session actually wanted to inspect. The lesson I'd skipped:...