Vercel Schedules: Runtime Jobs, Queue Retries and Timing Limits

Vercel Schedules lets applications and agents create, change or cancel future work at runtime, without a deployment for each change. The public beta also adds one-time jobs, named timezones, private function targets and testing in Preview environments.

Vercel announced the product on November 4. For developers building reminders, reports or agent tasks, the practical decision is which target should execute the work and what happens when that execution fails. Official announcement

What changes from a static cron job?

A conventional job keeps its timing in configuration and changes when the application is deployed. Schedules supports that pattern and adds runtime-managed jobs for individual users. A customer can ask for a report tomorrow, then change the time without requiring a new deployment. Schedules overview

The schedule records when work should be dispatched. Your application still supplies the handler, checks current permissions and records the result. Creating a schedule does not prove that a report was generated or a notification reached its recipient.

Vercel describes Schedules as the replacement for Cron Jobs, with a migration path. Review the current migration documentation before changing an existing production job, especially if it relies on a particular endpoint or secret.

Which targets support static and dynamic jobs?

Static schedules can target a private function, HTTP path or Queue topic. Dynamic schedules target Queue topics only. Static schedules live in project configuration and sync on deployment. Dynamic schedules are created through the SDK, CLI or API and take effect immediately. Target comparison

One-time work is dynamic. Both approaches support recurring work, but a runtime-created reminder is not simply a direct function timer. Its Queue consumer must accept the payload and carry out the task.

For a multi-tenant application, bind the tenant identity on the server. Check that the caller owns a schedule before allowing changes, then recheck the user’s current permissions when the task runs. Vercel’s launch example uses a tenant namespace and a user identifier; neither should be accepted as trusted merely because an agent supplied it. Agent example

What happens when a run fails or arrives twice?

Function and path targets do not retry when the handler fails or times out. Queue targets use Queue retries until delivery succeeds or the message expires. The documentation recommends a Queue topic when failed work must be retried. Delivery concepts

Duplicate delivery remains possible. Each occurrence has an execution ID that stays the same across its deliveries. My recommendation is to use that ID in a durable record that prevents the same business action from being completed twice.

For an email digest, test a duplicate delivery and a crash during processing using test recipients. Confirm what happens if the email provider accepts the message before the application records success. A handler that merely checks a local flag can still duplicate an external action in that failure window.

Runs are also independent, so a slow job can overlap the next occurrence. Decide whether overlapping work is acceptable or needs an application-level lock.

How precise is the timing?

Schedules uses a jitter window. A job scheduled for 09:00 with five minutes of jitter can start between 09:00 and 09:05. Hobby uses a 15-minute window; Pro and Enterprise support one to 15 minutes with a one-minute default. Hobby recurring jobs can run at most every 15 minutes. Timing rules

Named IANA timezones follow daylight saving time; the default is UTC. For a Canadian customer asking for a morning report, store the intended timezone and test around clock changes. Communicate an expected delivery window rather than promising an exact second.

Delayed delivery is another case to plan for. Some recurring occurrences expire and are skipped if Vercel cannot deliver them within the documented window. One-time and manually triggered runs do not use that expiry rule. A time-sensitive handler can compare the scheduled time with the current time and decline stale work. Late-run behavior

What changes across environments and rollbacks?

Schedules are separated by environment or Preview branch. New static schedules are active in Production and inactive in Preview; custom environments default to inactive unless configured otherwise. Enable a test schedule deliberately and give it test credentials and destinations. Environment behavior

Static definitions sync when the current deployment changes, including a rollback. Dynamic schedules survive deploys, promotions and rollbacks, and run against whichever deployment is current when they fire. Keep older payloads compatible with the application version you might restore.

My rollout check is to create a disposable dynamic job, deploy a handler change, then exercise the rollback path. Verify which version receives the payload and what the downstream system records. These are proposed checks, not a claim that FindMilan has tested your project.

What limits and costs should teams review?

The beta limits count schedules across projects, environments and branches at team level. Current documentation lists 1,000 schedules for Hobby, 10,000 for Pro and 100,000 for Enterprise, with a 16 KB payload limit. Limits can change before general availability. Plan limits

Hobby also limits dynamic creations and runs per billing period. Exceeding those limits blocks relevant operations and skips scheduled runs. A downgrade or transfer to Hobby deletes schedules whose frequency or jitter is incompatible, so review those settings before changing plans.

Execution uses the resources of the target: Functions invocations for function and path targets, and Queue messages plus consumer execution for Queue targets. Include those resources in a cost estimate. Disable or delete unwanted schedules to stop their usage. Usage rules

A useful first production pilot

Start with a low-impact report using test data. Verify permission changes, duplicate delivery, failure recovery, cancellation, timezone handling and the destination receiving the result. Keep an owner for failed and skipped work.

For help integrating those checks into a customer portal or SaaS application, see my website development service and the TransitFriends project. The useful outcome is a task that reaches its intended result with evidence, alongside a clear recovery path when it does not.