Cron jobs

A cron job runs something on a schedule: a deployed function, an HTTPS request to any public URL, or one SQL statement on your database. Each run is a durable background job with retries, a timeout and a history (succeeded, failed, skipped, missed), so a job never runs twice for the same time even when several servers see it due.

#Schedule expressions

Five fields — minute hour day-of-month month day-of-week — or a macro. The console and sov functions schedules preview show the next runs before you save.

• Lists 1,15, ranges 1-5, steps */10, 10-50/20 and 5/15 (from 5, every 15); names JAN–DEC and SUN–SAT; 7 is Sunday too.
• Dates that never happen (0 0 30 2 *) are refused when you save; rare ones (0 0 29 2 *) are fine.
• Time zones: pick any IANA zone (Asia/Kolkata, Europe/London, America/New_York); the default is UTC. Daylight saving is handled: a time skipped when clocks go forward runs once just after the change (02:30 runs at 03:30), a time that happens twice runs once — except expressions with * in the hour field, which keep their interval through the repeated hour.

#Create a cron job

sov functions schedules preview '0 9 * * MON-FRI' --tz Asia/Kolkata
sov functions schedules create '0 3 * * *' -f cleanup --tz Asia/Kolkata --overlap skip --name "Nightly cleanup"
sov functions schedules create @hourly --url https://hooks.example.com/ping -H 'Authorization: @secret:HOOK_TOKEN'
sov functions schedules create '*/15 * * * *' --sql 'SELECT refresh_leaderboard()' --timeout 20
sov functions schedules run <schedule-id>        # run it now
sov functions schedules runs <schedule-id>       # history

#Targets

#Retries, timeouts and overlap

• Tries per run (max_attempts, default 3, up to your plan's tries per event): a failed try is retried with backoff; the last failure is kept under Dead letters.
• Timeout (timeout_sec): lowers the run's limit below the function's or plan's; for SQL it is the statement timeout.
• Overlap — allow (default) runs every slot; skip skips a slot while the previous run is still going and logs it as Skipped.
• Run now queues one run immediately without changing the regular times (it follows the overlap rule).
• Slots missed while the scheduler was down are logged once as Missed, and the latest one runs late — they are not replayed one by one.

#Secrets

Never put a key in a payload, header or body: write {"$secret": "NAME"} instead. The value is filled in when the job runs (from the function's secrets for functions, the project and environment secrets for HTTPS and SQL), and logs show only the name. Plain values under names like password, token or api_key are shown as [redacted]; sending [redacted] back on an edit keeps what is stored. Payloads are at most 256 KB.

#Environments and the kill switch

A schedule belongs to the environment it was made in and runs that environment's function; staging never lists or changes production's schedules. Deleting a function removes its schedules in that environment only. If Sovaria support switches background runs off for an organization (abuse, a runaway loop), its slots are skipped and logged until they are switched back on.

#Compared with Supabase Cron

#Plans

Each run counts as one invocation (fn.invocations_month) and, for functions, its compute. Run history is kept as long as your plan keeps function logs (fn.log_retention_hours). See Plan limits.

#Coming from Firebase or Supabase?

Moving an existing app? Migrate from Supabase or Firebase imports users (with their passwords), data, files and rules.