Vercel Schedules launches one-off and recurring tasks without redeployment

Cron works well when developers know the schedule in advance: delete expired records at 2 a.m., refresh an index once a day, or synchronize data every ten minutes. Problems begin when the user, rather than the developer, chooses the time—and does so after the application has already been deployed.

Consider a simple request to an agent: “Tomorrow morning, collect the top five Hacker News stories and prepare a short summary.” In a traditional design, the application stores the request and execution time in a database, while a separate cron job regularly checks which tasks are due. It works, but the useful feature comes with supporting infrastructure: a jobs table, a polling mechanism, locks, retry handling, and cancellation logic.

Vercel has introduced Schedules, a service that lets applications create, modify, and cancel one-off and recurring jobs at runtime. This does not require changing the project configuration or redeploying the application. The service is now in public beta.

How it works

The application sends Vercel a time, time zone, execution target, and payload. A schedule can be created through the JavaScript SDK, API, or CLI. When the specified time arrives, Vercel delivers the stored data to the designated Vercel Queues topic, where application code receives the message and performs the work.

In Vercel's example, the agent is given a scheduleTask tool. The user describes a task, the model calls the tool, and the tool creates a one-off schedule containing the user and tenant identifiers. The next day, a worker reads the message from the queue, checks the user's current permissions, launches the agent, and stores the result.

This distinction matters: the schedule answers only the question of when to hand off the work. The application remains responsible for performing that work, checking access, storing the result, and handling errors.

For tasks known in advance, static configuration remains available through vercel.json or the Build Output API. A daily database cleanup, for example, can be linked to a private function and a specific time zone. Vercel invokes that function directly, without a public HTTP endpoint, and independently verifies that the trigger came from the scheduling service.

What changes for developers

The main benefit is the disappearance of a homegrown database-polling layer for user-defined timers. A schedule becomes a separate managed object that can be created, rescheduled, or canceled from a running application. Execution history appears in the Vercel dashboard, and a job can be triggered manually for testing.

Schedules supports Preview deployments and custom environments. This means a worker can be tested before production without waiting for its actual trigger time. Local development is available through vercel dev.

However, the service should not be treated as a complete replacement for a queue or background-processing engine. Dynamic jobs are delivered through Vercel Queues, so teams still need to plan for redelivery, worker idempotency, and observability. If an operation charges money or sends an email, a retry must not perform the action twice.

There is also a product risk: a user may lose access between the creation of a schedule and its execution. Vercel explicitly demonstrates the correct approach—recheck permissions before launching the agent instead of trusting data saved the previous day.

Practical takeaway

If an application already runs on Vercel and needs reminders, delayed agent actions, or recurring maintenance jobs, Schedules is worth testing in a Preview environment. A sensible starting point is a noncritical task: add idempotency and logging, then test cancellation, time-zone changes, and redelivery.

A team that already has a reliable scheduler and queue has no urgent reason to migrate. For a new product, however, Vercel Schedules reduces the amount of custom infrastructure and turns a user's “do it tomorrow morning” request into an ordinary API call instead of a separate subsystem.