web dev//backend//cron job

A cron job is a task a system runs automatically on a fixed schedule (every night at 03:00, every five minutes, on the first of the month), named after the Unix scheduler `cron` that introduced the notation. It covers the recurring chores of any backend: nightly cleanups, periodic syncs with an external API, daily reports, certificate renewals, cache warming.

A cron job is a task a system runs automatically on a fixed schedule (every night at 03:00, every five minutes, on the first of the month), named after the Unix scheduler cron that introduced the notation. It covers the recurring chores of any backend: nightly cleanups, periodic syncs with an external API, daily reports, certificate renewals, cache warming.

The schedule is a cron expression of five fields, minute, hour, day of month, month and day of week:

Copy

0 3 * * * every day at 03:00 */5 * * * * every five minutes 0 9 * * 1 every Monday at 09:00

On a server the system's cron daemon reads them from a crontab; on hosting platforms the same expressions trigger functions (Vercel cron jobs are scheduled functions defined in vercel.json).

A cron job knows the clock, nothing else. It fires whether or not there is work, and whether or not the previous run has finished, so a job that sometimes takes longer than its interval can overlap itself; a lock or an is it already running check prevents two copies from processing the same rows.

Missed runs are silent. If the machine was down at 03:00 the job simply did not happen, and nothing complains; a job that matters records its last success, and an alert fires when that timestamp gets too old.

Every environment needs its own decision. A cron job copied into a preview environment that sends real emails or charges real cards does real damage; scheduled tasks are switched off or pointed at test services outside production.

Time zones and daylight saving shift the schedule. Servers usually run in UTC, so 03:00 is 05:00 in Madrid in summer and 04:00 in winter.

Cron supplies the when, and nothing more.

Overlap, failure, retries and the environment it may touch are the job's own responsibility.

When a scheduled trigger creates more work than one run can finish within its timeout, the cron job only fills a job queue and workers do the rest.