Cron Schedules for Cleanup Jobs

Cleanup jobs are the silent maintainers of production health — they prevent the slow accumulation of stale data, expired records, temporary files, and log archives that eventually cause disk exhaustion, database bloat, and degraded query performance. Unlike visible features, cleanup jobs fail silently: the logs simply stop rotating, the temp directory fills up gradually, and you only notice six months later when a server runs out of disk space at 2 AM. This collection shows eight cleanup scheduling patterns covering the most common production cleanup tasks. Daily log rotation at 3 AM (0 3 * * *) is the most universal cleanup job — nearly every production server needs it. Weekly deep cleanup at 4 AM Sunday (0 4 * * 0) is appropriate for more expensive operations like rebuilding database indexes, purging old analytics data, or archiving completed records to cold storage. Monthly cleanup at 1 AM on the first (0 1 1 * *) suits retention policy enforcement jobs that archive or delete records older than 90 or 365 days. Session table cleanup is a critical database health task that many applications neglect: web frameworks that use database-backed session storage (Redis or PostgreSQL session tables) accumulate millions of expired session records over time. A daily cleanup job running WHERE expires_at < NOW() keeps the table lean and ensures session lookups stay fast. Without it, the session table can grow to hundreds of millions of rows and turn a microsecond session lookup into a multi-second table scan. Temp file cleanup (30 2 * * *) addresses another common accumulation: applications that generate temporary files for file uploads, export generation, or report processing sometimes fail to clean up after themselves when errors occur. A daily sweep of the temp directory removing files older than 24 hours catches these orphaned files before they fill the disk. The */30 * * * * expression (every 30 minutes) is appropriate for cache invalidation jobs that synchronize a Redis or CDN cache with database changes. Running too infrequently means stale cache hits; running too frequently adds unnecessary database load. 30 minutes is a reasonable middle ground for most content that doesn't require real-time freshness. The annual cleanup (0 6 1 1 *) pattern for archiving previous-year data deserves special attention: because it fires only once per year, you cannot rely on observing a failed run and fixing it — you'll wait another 364 days for the next opportunity. Run annual cleanup scripts manually and on a test dataset before scheduling them, and set up specific monitoring to alert if the job fails to execute within the expected January window. Tips: always run cleanup scripts with a --dry-run flag first to confirm which records would be deleted before enabling live deletion. Add monitoring that alerts if a cleanup job hasn't run within twice its expected interval, catching the case where the cron job itself fails to execute.

0 3 * * *
0 4 * * 0
0 1 1 * *
30 2 * * *
0 5 * * 6
*/30 * * * *
0 0 * * *
0 6 1 1 *