A reminder webhook has two jobs: wake up at the right time, then hand work to a consumer that can survive a retry. Those jobs should not share one long-running request. For a game, the practical design is a public cron target that enqueues a small reminder message, followed by a worker that performs the delivery and records only the status it needs.

Short answer: use cron for the trigger, a queue for the work, and an idempotency key derived from the reminder ID and scheduled occurrence. That keeps the trigger fast and makes the normal case cheap to operate without pretending that retries are free. The latency-versus-cost decision is visible in the boundary: a shorter schedule improves freshness, while a longer worker retry window absorbs transient failures.

What changes when a webhook is retried?

Before the boundary, the cron request tries to send the reminder itself. A slow game-notification provider then holds the request open, a timeout causes a retry, and the player may receive two messages.…