Scheduled Job

Outcome: Design or review Scheduled Job for this system while keeping data correct, secure, and easy to operate. User context: A Kubernetes CronJob starts a backup every day at 02:30 in `Asia/Taipei`. Its policy skips a new run while the last one is active. It also limits how late a missed run may start. The backup uses the planned start time as its repeat-safety key. Technical concept or control: Scheduled Job. Why it fits: Use it for regular backups, reports, cleanup, or other work tied to the clock. Define the time zone, late-run rule, overlap rule, and safe repeat behavior. Do not use it when: Do not assume a schedule runs at the exact second or exactly once. Use an event trigger when the work belongs to a data change instead of a clock time. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.