Cron Job Management Template for PMs

Start by documenting all crontab entries using this template. Then migrate jobs one at a time to the new scheduler (Airflow, Temporal, Kubernetes CronJobs), starting with the lowest-priority jobs. Keep the old cron entry disabled (not deleted) as a rollback option for 30 days. Verify each migrated job runs successfully for a full cycle before removing the old entry. The [CI/CD Pipeline Template](/templates/ci-cd-pipeline-template) covers how to deploy scheduler configuration changes safely.

Use UTC for all cron schedules. Convert business requirements ("send the report at 9 AM Eastern") into UTC at documentation time and note the local time in the "human-readable" column. For jobs affected by daylight saving time transitions, document the expected behavior (does "9 AM local" shift by an hour or stay fixed?). Kubernetes CronJobs support timezone natively since v1.27.

Document resource requirements per job and check for schedule conflicts during the quarterly review. If two jobs both need heavy database access, stagger them by at least the P95 duration of the first job. Use resource limits (CPU/memory quotas) to prevent one job from starving another. Track job queue wait times to detect scheduling congestion.

Track the [failure rate](/glossary/prioritization) per job over 30 days. If a job fails more than 5% of runs, investigate root causes: flaky infrastructure, data quality issues, or resource contention. Set a policy: jobs with >10% failure rate over 30 days get a dedicated fix sprint or are decommissioned. Do not let chronically failing jobs become accepted background noise.

Separate them if possible. Resource-heavy batch jobs (database vacuums, aggregations, index rebuilds) can spike CPU and memory usage, increasing latency for production requests. Use a dedicated node pool or namespace with resource quotas. If separation is not feasible, schedule heavy jobs during low-traffic windows and set strict resource limits. ---