Short answer: a flexible cron job API allows global report timing customization when the time-zone rule and run identity stay in your application. Use the cron job only to start the work, then put the daily game report cleanup behind a queue. That boundary lets you replace the scheduler without rewriting delivery semantics.

The problem is easy to underestimate. A global game may need a daily report email and cleanup at 02:30 for each player region, while the cleanup itself can outlive a web request. A schedule that says “every 24 hours” is not the same policy as “02:30 in the player’s IANA time zone.” The trigger also does not make duplicate delivery safe.

Which boundary keeps a global cleanup replaceable?

Treat local time as application policy. Store the IANA location, the intended local hour, and a deterministic run identity such as cleanup:2026-10-24:asia-shanghai . The scheduler adapter translates that policy into a provider request.…