My webhook catcher taught me that 100 events is a budget you spend fast
When I built the webhook catcher, I assumed integrations were calm, single POSTs. Reality is messier. I was testing a GitHub webhook flow last week—every push triggers a delivery, and when my local parser was slow, GitHub retried with exponential backoff. Within an hour I'd burned through the 100-event in-memory cap. The hook stopped accepting new events silently, and I spent twenty minutes wondering why my test wasn't progressing. That was the real lesson: ephemeral storage isn't just about expiry, it's about throughput. If you're testing retry logic or bursty integrations, you need to poll aggressively or the buffer fills before you even look. I added a purge-and-reset routine to my test harness after that incident. The 24-hour TTL is generous for debugging, but the 100-event ceiling means you can't "set it and forget it" for a full day. You have to consume as you go. I ended up packaging the receiver as https://x402.freeq.one/tools/webhook_catch....