Cron job
A task your server runs automatically on a clock: every night at 2am, every five minutes, the first of the month.
See it
What it is
A cron job is code that runs on a clock instead of in response to a user. The name comes from Unix 'cron', whose five-field schedule syntax (minute, hour, day of month, month, day of week) is now the lingua franca: '0 2 * * *' means 2am every day, '*/5 * * * *' means every five minutes. The same syntax shows up in GitHub Actions schedules, Vercel Cron, Cloudflare Triggers, and Postgres pg_cron.
Reach for one when work is tied to time rather than to a request: nightly reports, expiring old sessions, refreshing a cache, retrying failed payments, sending the Monday digest. If the work is triggered by something a user just did, you want a job queue instead.
Three gotchas eat people alive. Timezones: most schedulers fire in UTC, so '0 9 * * *' is not 9am for your users. Overlap: if the job takes 12 minutes and runs every 10, you now have two copies fighting over the same rows, so take a lock. And delivery is best effort, not guaranteed, so make the job idempotent and log every run, because a cron that silently stops firing is invisible until someone asks where last week's report went.
Ask AI for it
Add a scheduled cron job that runs [TASK] on the schedule [e.g. every day at 02:00 UTC, cron expression '0 2 * * *']. Put the actual work in a plain exported function so it can be called and tested directly, and have the scheduled handler just invoke it. Make the job idempotent (running it twice for the same period must not duplicate anything), take an advisory lock or set a running flag so overlapping runs are skipped, wrap the body in try/catch, and record start time, end time, row counts, and any error to a job_runs table. Read the schedule from config, document the timezone explicitly, and keep the job under the platform's execution time limit by processing in batches.