Aurabase Logo
aurabasedocs
docs›Services›Cron

Cron

Schedule the invocation of an Edge Function on a cron expression. Each deadline puts a job in the same queue as the asynchronous invocations, consumed by the pool of workers — without retrying in case of failure.

5 min read·Level intermediate·Revised on Aug 15, 2026
This English text was generated automatically from the French original and has not been reviewed yet.
#
Overview

One more trigger for your functions

The aura-functions service can invoke an Edge Function on a schedule, in addition to synchronous HTTP invocations and manually queued asynchronous jobs — see /docs/functions. There is no separate “cron” function: any deployed function can be targeted by a schedule.

Info

Cron does not replace an SQL scheduler. For purely database tasks (refreshing a materialized view, purging a table), the Postgres extension pg_cron — which can be activated from the Studio, see /docs/database — avoids the HTTP round trip to a function.

#
Mental model

The cron threads, it does not execute

A cron deadline does not launch the function directly: it creates a job in the queue (the same tables and the same worker pool as POST /v1/functions/:projectId/jobs), with a payload frozen at the time of cron creation. The job is then consumed by a worker like any other job.

cycle of a deadlinetext
DEADLINE  ────▶  the in-process scheduler triggers at the scheduled time
ENQUEUE   ────▶  a job is created (function_name + cron payload)
WORKER    ────▶  the worker pool consumes the job, invokes the function
FAILURE     ────▶  max_attempts=1 → dead (DLQ) immediately, no retry
SUCCESS    ────▶  last_run + next_run updated on cron line
Astuce

When the service is restarted, all active crons of all provisioned projects are reloaded from the base and rescheduled — the task list is not persisted in memory alone.

#
Primitives

What the scheduler provides

In-process scheduler

tokio-cron-scheduler + the cron crate in aura-functions: no external service, in-memory scheduling rescheduled on startup.

§ scheduler

Each deadline = a job

The cron does not execute anything itself: it threads a job (like functions.invoke in asynchronous mode), consumed by the same pool of workers.

§ pipeline

Without retry

A job created by the cron has max_attempts=1: a failure switches it directly to DLQ (dead), unlike classic asynchronous jobs (3 attempts by default).

§ failure

Last_run/next_run tracking

Each trigger timestamps last_run and pre-calculates next_run from the stored expression — visible via listCronJobs().

§ observability

#
Examples

Create, list, delete

app/cron.tstypescript
import { createClient } from '@aurabase/aurabase-js'

const aura = createClient(url, projectId, serviceRoleKey)

# 5-field expression (min hour day month dsem) — seconds are
# implicitly 0. A 6-field expression (with seconds) is also accepted.
await aura.functions.createCronJob(
  'rollup-15min',      // name, unique per project
  '*/15 * * * *',      // planning
  'rollup',             // function invoked at each deadline
  { payload: { minutes: 15 } },
)

const { data: crons } = await aura.functions.listCronJobs()
await aura.functions.deleteCronJob('rollup-15min')
Astuce

The name of a cron is unique per project and serves as an identifier for deletion (DELETE /v1/functions/:projectId/cron/:nom) — there is no UUID to remember on the client side.

#
Points of attention

What cron doesn't do (yet)

No dedicated CLI command

Unlike function secrets (aura secrets), there is no aura functions cron command today: management of scheduled tasks goes through the SDK or the REST API, not through the CLI.

No automatic retry

A job from the cron fails directly in dead (DLQ) on the first attempt — max_attempts is worth 1, compared to 3 by default for a classic asynchronous job. A cron-invoked function must therefore handle its own replays if the underlying operation is to be guaranteed, or you must monitor the DLQ (GET /v1/functions/:projectId/jobs/dlq) and replay manually.

Last updated · Aug 15, 2026