starter.wiki

Infrastructure

Cron & Scheduled Jobs

Choose a time-based invocation model by schedule type, target, retry, durability, time-zone behavior, and execution ownership.

Recommendation

Separate the clock trigger from the work it starts.

Platform cron, runtime-native triggers, standalone cloud schedulers, and durable scheduled tasks provide different invocation and recovery guarantees.12

For: Application and platform teams running recurring or one-time work on a schedule

Main trade-off

A more capable scheduler improves delivery control and recovery while adding platform coupling, IAM, configuration, observability, and cost.12

Four scheduling models

Choose whether the scheduler only invokes a target or also owns durable execution and run recovery.

  1. Schedule semantics

    Define recurring versus one-time schedules, frequency, UTC or time-zone behavior, drift, overlap, catch-up, and cancellation.3

  2. Target and delivery

    Choose HTTP, runtime handler, cloud target, or task execution and set authentication, retry, and dead-letter behavior.4

  3. Execution durability

    Decide whether the trigger is enough or work needs durable retries, checkpoints, history, and recovery after invocation.4

  4. Ownership and limits

    Verify platform frequency, concurrency, duration, account, target, observability, billing, and failure-handling boundaries.4

Scheduling routes

Use a lightweight trigger for bounded idempotent work; adopt a stronger scheduler or durable executor only when its controls are required.

A Vercel application needs simple recurring HTTP invocation

Evaluate Vercel Cron Jobs.

A cron expression can invoke an existing application route with minimal additional infrastructure.

Verify: The application owns authentication, idempotency, overlap, function constraints, and recovery after invocation.12

A Workers application needs a bounded scheduled handler

Evaluate Cloudflare Cron Triggers.

The runtime-native trigger directly invokes scheduled Worker logic.

Verify: UTC behavior, Worker limits, account constraints, and lack of general target diversity must fit.12

AWS needs independent recurring or one-time schedules

Evaluate EventBridge Scheduler.

Independent schedule lifecycle, target choices, retry policy, and dead-letter support fit cloud orchestration.

Verify: IAM, target configuration, AWS coupling, and execution after delivery remain explicit.123

Scheduled work itself needs durable execution

Evaluate Trigger.dev Scheduled Tasks.

One platform can own the time trigger, durable task run, retries, and run history.

Verify: A lightweight trigger is simpler when durable task semantics and another compute platform are unnecessary.124

Boundary: Background Jobs owns recoverable execution after invocation. Message Queues owns transport. Repository workflow schedules belong to CI/CD rather than general application scheduling.

What happens after the clock fires

Successful invocation is not the same as successful completion of business work.

Schedule types
Recurring cron, one-time schedules, time zones, overlap, and cancellation vary by route.3
Target model
HTTP routes, runtime handlers, cloud targets, and managed task workers have different authentication and delivery paths.2
Recovery
Retries, dead letters, durable checkpoints, run history, and replay can belong to the scheduler, executor, or application.3
Limits
Frequency, duration, concurrency, target, account, and billing boundaries require current verification.1

Official resources

Use the primary documentation to verify runtime behavior, operating limits, service boundaries, and current commercial terms.

DocumentationVercel Cron Jobs

Sources

Official documentation supporting the routes and decision boundaries on this page.

  1. 1
    Vercel Cron Jobs

    Vercel · Accessed Official

  2. 2
    Cloudflare Cron Triggers

    Cloudflare · Accessed Official

  3. 3
    EventBridge Scheduler introduction

    Amazon Web Services · Accessed Official

  4. 4
    Trigger.dev scheduled tasks

    Trigger.dev · Accessed Official