Supabase cron jobs

Supabase cron jobs for recurring product workflows

Supabase gives developers a good stack for database-backed apps, auth, and serverless functions. The scheduling question shows up quickly: how do you run recurring work on time without turning your app into scheduler infrastructure?

What teams usually mean by Supabase cron jobs

Sometimes the requirement is simple. You need one nightly cleanup, one hourly sync, or one daily report job. In that case, a fixed schedule that triggers a function or a backend task can be enough.

The requirement changes when schedules belong to product data. A customer wants a weekly digest every Monday at 9 AM. Another tenant wants a retry every 20 minutes. A user pauses reminders, then re-enables them later. At that point, the schedule is not deployment config anymore. It is application state.

Where static schedules stop fitting

You need one schedule per user, workspace, or integration.
The cadence changes from your app UI or backend logic.
You need pause, resume, update, and delete operations from code.
You want delivery history for customer-specific failures.
You do not want recurring work tied to a long-lived worker you maintain yourself.

A practical pattern for Supabase apps

A clean pattern is to let your Supabase app own the business rules while an external scheduler owns time-based delivery. Your app creates a recurring webhook through an API, stores the returned job id, and handles the actual workflow in a protected HTTP endpoint.

// Example scheduled endpoint for a Supabase-backed app
export async function POST(request: Request) {
  if (request.headers.get("x-cron-secret") !== process.env.CRON_SECRET) {
    return new Response("Unauthorized", { status: 401 });
  }
  const body = await request.json().catch(() => ({}));
  await runDigestForWorkspace(body.workspaceId);
  return Response.json({ ok: true });
}

Example: weekly customer digest scheduling

Imagine every workspace in your product can enable a weekly digest. When the workspace saves its preference, your backend creates or updates a recurring webhook instead of editing infrastructure config.

curl -X POST https://api.croncoco.io/jobs \
  -H "Authorization: Bearer coco_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"workspace-weekly-digest","cron_expression":"0 16 * * 1","webhook_url":"https://your-app.com/api/scheduled/digest","headers":{"x-cron-secret":"YOUR_SECRET"},"payload":{"workspaceId":"ws_123"}}'

Now the schedule lives next to the workspace record in your product model. Your app can disable it when the workspace downgrades, update it when the user changes timezone, and inspect delivery history when support needs answers.

Why this fits serverless systems better

Supabase apps often combine edge functions, APIs, and database-triggered flows. That architecture works best when recurring execution is event-driven and stateless. An external scheduler calling a small webhook endpoint keeps the scheduled path simple.

It also avoids a common failure mode: building a sidecar scheduler service that gradually turns into a queue, a retry system, an audit log, and an operations burden.

When CronCoco is the better fit

CronCoco is useful when your Supabase app needs API-created recurring webhooks, not just one fixed cron line. If schedules are customer-owned, tenant-specific, or mutable from the product, CronCoco gives you a cleaner boundary: your app decides what should run, CronCoco decides when to call it.

For related patterns, see multi-tenant cron jobs, how to schedule API calls, and when to use a webhook scheduler API. If you want the endpoint shape and request fields, start with the Create job docs.