Put the inbound retry back on an hourly cron

The decision

Restore `/api/cron/inbound-retry` to `15 * * * *`, cut its staleness window from 30 hours to 4, and take the Hobby assumptions out of the code and the runbook — while keeping the in-request drain that was built to compensate for them.

Why, at the time

The project had moved to a Vercel team on the Pro plan, which allows a cron every minute rather than once a day. The daily schedule, the ±59-minute slack the staleness windows were sized for, and the comments explaining all of it were compensating for a constraint that no longer applied. Leaving them was the real risk: a stale platform assumption written into the code is precisely what produced the twenty-six-day outage, and the second reader has no way to tell a live constraint from an expired one.

What happened

Committed on 11 September. Whether an hourly retry measurably shortens how long a stuck message waits cannot be known yet — there are no organizations in the database and no inbound volume to observe. What is already true is narrower: a test now fails if a schedule in vercel.json and its staleness window in the code disagree, which is the drift that left an hourly job with a thirty-hour window in the first place.

Every entry in this ledger is real and was checked against the commit or migration that carries it. Want to keep your own this way? Start with the free decision log template.