Skip to content
RELKIT
Esc
↑↓navigate↵open⌘Jpreview
On this page

Schedules

Run jobs on provider-backed schedules.

Start a job on a schedule by declaring its cron rule and timezone.

Schedules belong to jobs and use the same task input and admission rules as an on-demand trigger.

/** Schedules the cleanup task daily at midnight UTC with the established input and skip-misfire policy. */
import { defineJob } from "@relkit/app/jobs";
import cleanupOrders from "../tasks/cleanup-orders.task.js";

const cleanupOrdersJob = defineJob({
  name: "cleanupOrders",
  id: "orders.cleanup",
  task: cleanupOrders,
  schedules: [
    {
      id: "dailyCleanup",
      cron: "0 0 * * *",
      timezone: "UTC",
      input: { before: "30 days ago" },
      misfire: "skip",
    },
  ],
});

export default cleanupOrdersJob;

Use schedules, an array of definitions with an explicit id, canonical input, and either a cron/timezone pair or an interval. Schedule operations return a receipt with an operation ID; they do not pretend that a provider accepted a write when its outcome is unknown.

Use an explicit job ID and keep schedule ownership in source control. relkit jobs schedules list|get|upsert|pause|resume|delete manages the registered definition; each write returns an operation ID that can be audited.

Schedules are provider-backed. Do not run a second process-local scheduler as a fallback: it can double-trigger work after a restart. Check relkit jobs capabilities for the selected provider’s cron, interval, timezone, overlap, and misfire support. The current Inngest path supports UTC cron schedules; interval and richer misfire policies are not silently emulated.

Pausing a schedule prevents new admissions and does not cancel runs already accepted. Delete or change a schedule only after checking in-flight runs and the migration impact on dedupe keys.

Reference and source