Run a cron job at a random time: shell delays and hosted windows

Several jobs all starting at 03:00 can hit the same database or API together. To vary their start times, add a random delay to a cron-triggered script or let a scheduler choose a time inside a window. Use the script when you already manage the machine; use a hosted window when the job has an HTTPS endpoint.

Random timing can spread scheduled work across a period or make a recurring prompt less predictable. It does not replace concurrency limits, retries, or monitoring.

A Bash script with a random delay

Put the delay in a script rather than directly in the crontab. Save this as /usr/local/bin/random-nightly-job and make it executable:

#!/bin/bash
set -euo pipefail

# Wait between 0 and 3599 seconds, then replace this process with the job.
sleep "$((RANDOM % 3600))"
exec /usr/local/bin/nightly-job

Call it from your user crontab:

0 3 * * * /usr/local/bin/random-nightly-job

This selects a delay after 03:00 in cron's configured timezone. Bash supplies $RANDOM; cron normally uses /bin/sh. Keeping the expression in a separate script also avoids cron's special handling of %. System crontabs additionally need a username field. See the crontab manual.

The modulo expression is slightly biased, so this is a simple load-spreading example, not a statistically uniform sampler. A sleeping process remains alive until it starts the job. If runs could overlap, add a locking strategy appropriate to your environment. Log the actual start and finish times in your job.

Check which cron implementation you have

Randomness extensions are not portable. Cronie's RANDOM_DELAY uses a scaling factor chosen when the daemon starts. Its ~ ranges select a value when the crontab is parsed. Neither should be assumed to choose a fresh time on every run. Check your installed version's manual before relying on an extension.

If your current scheduler already provides the timing and observability you need, keep it. A hosted service becomes useful when you want to manage the schedule independently of the machine that does the work.

Schedule a webhook inside a window

Untimely lets you define an interval, frequency, allowed days, and a time window. It creates trigger times within those rules and sends an email or calls a webhook.

Create an API key in dashboard settings, then create an event:

curl -sS "https://untimely.app/api/events" \
  -H "Authorization: Bearer $UNTIMELY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: nightly-random-window-001" \
  -d '{
    "name": "Nightly job in a random window",
    "interval": 1,
    "frequency": 1,
    "betweenTimeStart": "02:00",
    "betweenTimeEnd": "04:00",
    "actionType": "WEBHOOK",
    "webhook": {
      "method": "POST",
      "url": "https://example.com/jobs/nightly"
    }
  }'

Replace the example URL with your HTTPS handler. This requests one occurrence per one-day interval inside 02:00–04:00 UTC. This example omits timezone, so its window uses UTC. Include an IANA timezone such as America/Toronto to use local hours instead. The trigger is processed by the delivery service; it is not a promise of second-precise execution.

Use a different idempotency key for a different event. Keep credentials out of source control, protect your receiving endpoint, and make its work safe to retry. Inspect event run history to check delivery results. The API guide covers authentication and reading the event back; the API schema documents supported fields.

Pick the smallest setup that fits

• A local script: a Bash delay may be enough when you already operate the machine.
• An HTTPS job: a managed random window keeps scheduling separate from execution.
• A personal prompt: use an email event; you do not need a webhook or code.

Ready to schedule an HTTP job? Create your first webhook event, or read the cron jitter setup guide. For email ideas, try 10 everyday reminders.