Docs · Guides

Scheduled jobs.

Run a URL in your own app on a repeating schedule — a daily digest, an hourly sync, a nightly cleanup — without wiring up a third-party cron service. Canner calls your endpoint on the schedule you set and keeps the run history.

A scheduled job is a cron expression plus a webhook URL. On each tick Canner sends an HTTP POST to that URL; your app does the work and returns a 2xx to report success. Because the job is just a request to your own endpoint, there is no separate runtime to learn — you write ordinary route code. To run SQL on a schedule instead of hitting a webhook, use scheduled SQL queries.

Create a job

Go to Compute → New job and fill in four things: the project the job belongs to, a name, the webhook URL to call (usually a route on your own app, e.g. https://your-app.canner.ca/api/cron), and a cron schedule. An optional description helps you remember what it does.

The schedule

Schedules use standard 5-field cron — minute hour day-of-month month day-of-week — and all times are UTC. The form shows you the next run time as you type so you can sanity-check it.

0 9 * * *      # every day at 09:00 UTC
*/15 * * * *   # every 15 minutes
0 0 * * 1      # every Monday at midnight UTC
0 */6 * * *    # every 6 hours

Writing the handler

Your endpoint should accept a POST, do its work, and return a 2xx status. A non-2xx response, a timeout, or a connection error is recorded as a failed run. Because the URL is reachable on the public internet, protect it — the simplest way is a shared secret you store as an environment variable and check on each request:

// app/api/cron/route.ts (Next.js) — any framework works
export async function POST(req: Request) {
  // optional: verify a shared secret you set as an env var
  if (req.headers.get("x-cron-key") !== process.env.CRON_KEY) {
    return new Response("forbidden", { status: 403 });
  }
  await runDailyDigest();
  return new Response("ok"); // 2xx = success
}

Runs, retries & history

Open a job to see its run history — each run is marked Succeeded, Failed, Timeout, or Running. You can trigger a job manually from its detail page to test the endpoint without waiting for the next tick. Long-running requests are cut off at the platform timeout and recorded as a timeout, so design handlers to finish quickly (or kick off background work and return immediately).

Plans

Scheduled jobs are available on every plan, with no cap on how many you can create. Plans differ by execution priority: jobs run best-effort on Starter, prioritized on Live, and with unlimited dedicated capacity on Dedicated. See Plans & limits for the full comparison.