SaaS scheduling guide

How to run multi-tenant cron jobs in a SaaS product

Multi-tenant cron jobs stop being a simple cron problem as soon as each customer needs its own schedule. At that point, schedules are product data, and your application needs a way to create, update, pause, and inspect them without redeploying code.

Why multi-tenant scheduling is different

A typical internal cron job runs one maintenance task for one application. A SaaS platform often needs one recurring workflow per tenant, integration, workspace, or user. Those schedules can differ by frequency, destination, payload, and timezone requirements.

One customer wants hourly syncs while another wants nightly syncs.
Each tenant needs its own webhook payload or authentication headers.
Support needs delivery history when only one tenant reports a missed run.
Account changes should pause or resume schedules immediately, not at deploy time.

Where static cron configuration breaks down

Deployment-level cron config works when the schedule is fixed for the whole project. It breaks down when recurring jobs belong to customer records in your database. You do not want a deployment pipeline to be the control plane for product-owned schedules.

The usual failure mode is trying to keep one large worker running and polling a schedules table. That creates extra infrastructure, operational noise, and more code for retries, observability, and backoff logic.

The better pattern: treat schedules as API-managed records

A cleaner model is to let your backend create one recurring webhook per tenant workflow. Your app keeps the business rules and tenant state. CronCoco handles the clock, triggering, and delivery attempts.

// Example: create one schedule per tenant
await fetch("https://api.croncoco.io/jobs", {
  method: "POST",
  headers: {
    "Authorization": "Bearer coco_YOUR_KEY",
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    name: "tenant-report-acme",
    cron_expression: "0 13 * * 1",
    webhook_url: "https://your-app.com/api/scheduled/report",
    headers: { "x-cron-secret": "YOUR_SECRET" },
    payload: { tenantId: "tenant_acme" }
  })
})

What your webhook handler should do

Your handler should verify a secret, read the tenant-specific payload, and run an idempotent workflow. The payload lets one endpoint serve many customer schedules cleanly.

// app/api/scheduled/report/route.ts
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();
  await runTenantReport(body.tenantId);
  return Response.json({ ok: true });
}

What to store in your own database

Keep the scheduler job id next to the tenant or workflow record that owns it. That gives your app a clean way to update the cadence, pause billing-related jobs, or delete schedules when an account churns.

Your internal tenant or workflow id.
The CronCoco job id returned at creation time.
The intended cadence and current status shown in your product UI.
Any audit metadata your team needs for support.

Where CronCoco fits

CronCoco is a good fit when recurring jobs are tenant-specific and you want an API instead of maintaining dedicated workers. Your app decides which schedules exist. CronCoco delivers the webhook on time and gives you a cleaner model for dynamic recurring work.

For related patterns, read how to create dynamic cron jobs in Next.js and when to use a webhook scheduler API. If you want to implement the flow directly, start with the Create job API docs.