Cron job

A cron job is a task scheduled to run automatically at fixed times or intervals on a server, such as every night at 2 a.m. or every Monday morning. It is the standard way to automate recurring work like backups, reports and data syncs without anyone clicking a button.

‍

What is a cron job?

A cron job is a command or script that a scheduler launches on its own at a defined time. The name comes from cron, the time-based job scheduler built into Unix and Linux systems. A background service reads a list of schedules and runs each task when its moment arrives, whether or not anyone is logged in.

It matters because much of the work that keeps a product healthy is repetitive: cleaning old records, sending digests, refreshing caches, renewing certificates. Scheduling these tasks removes manual effort and the risk of forgetting them, and it makes the result consistent: the same job runs the same way every time, at a moment when traffic is usually low.

‍

Cron syntax explained

Each job is a line in a file called the crontab. It starts with five time fields, followed by the command to run:

* * * * * command

• Minute (0-59)
• Hour (0-23)
• Day of month (1-31)
• Month (1-12)
• Day of week (0-7, where 0 and 7 are Sunday)

For example, this runs a backup script every day at 02:30:

30 2 * * * /usr/local/bin/backup.sh

An asterisk means "every value", a comma lists values, a dash sets a range and a slash sets a step: */15 * * * * runs every 15 minutes.

‍

Common uses of cron jobs

• Database backups and log rotation.
• Sending scheduled emails, reminders or weekly reports.
• Syncing data between tools or refreshing an external feed.
• Generating sitemaps and clearing expired cache or sessions.
• Running health checks and alerting when a service stops responding.

Managed platforms offer the same idea without a server: Supabase, Cloudflare Workers and most cloud providers let you schedule functions on a cron expression.

‍

Cron job vs webhook vs manual trigger

A cron job polls the calendar, a webhook waits for an event. Many automations combine both: a webhook handles the live event, and a nightly cron job reconciles anything that was missed.

‍

Best practices and common pitfalls

Make each job idempotent, meaning that running it twice produces the same result as running it once, because overlaps and retries happen. Log the output and monitor success, for example with a heartbeat ping to an uptime service, since a cron job that silently fails is worse than none. Use absolute paths and set the environment explicitly, as cron runs with a minimal one.

Watch the time zone: a server in UTC will not run a task at 9 a.m. Paris time unless you account for the offset and for daylight saving. Avoid stacking heavy jobs on the same minute, and add a lock so a slow run does not overlap with the next.

Finally, document every job: what it does, who owns it and what to do when it fails. Scheduled tasks tend to be forgotten until the day they break, and an undocumented one is hard to fix under pressure.

‍

Cron jobs at BeBranded

We use scheduled jobs, in code or in no-code tools like Make and n8n, to keep data synced and reports flowing without manual work. They are a building block of the workflows we deliver in our automation service.