Schedules and background jobs

Not everything an app does starts with a click. Some work runs on a clock; some work is too slow to make a visitor wait for it.

Cron: work on a schedule

A cron job is a task that runs at set times. The schedule is written as five fields: minute, hour, day of month, month, day of week. A few to read:

• 0 0 * * *: every day at midnight
• 0 9 * * 1: every Monday at 9:00
• */15 * * * *: every 15 minutes

The scheduler calls a path in your app (say, /api/send-digest) at those times. The app does the work when called; the scheduler only decides when. Times are in a fixed timezone, usually UTC, so 9:00 in Seoul is 0:00 UTC.

Queues: work in the background

When someone places an order, the receipt email should not delay the "thank you" page. The app puts a job on a queue and returns immediately. A worker picks the job up and sends the email seconds later.

Retries and idempotency

Background work fails sometimes: a mail server is busy, a network blips. Queues retry, usually with growing delays. That creates a new problem: a job that half-finished before failing will run again. Jobs must be idempotent, safe to run twice. "Send the receipt for order 42 if none has been sent" is safe; "send a receipt" is not.

Cron jobs need the same care. If a nightly run is late and the next one starts, both must not double-charge anyone.

Where DontCode fits

Insight Projects have a Cron Jobs page: give each job a name, the path it calls, and a schedule, then save. Dispatching, retries, and authenticating the call are handled by the platform. Plans cap how many jobs you can schedule and how many runs you get per month. Insight builds themselves run as background jobs, which is why the Builds page shows progress instead of making you wait on a spinner.