Vercel Schedules enters public beta, letting agents create, change and cancel timed tasks while the app runs

Scheduled work no longer has to change only with a deployment. Vercel Schedules lets agents and applications decide when work should happen while the application is still running, and create, change or cancel one-time and recurring schedules. Vercel Cron Jobs previously used a static approach, keeping timing in vercel.json or Build Output API configuration and syncing on deploy; agents interacting with users as work evolves need schedules updated in real time. Vercel's stated comparison is that the traditional solution stores the request and its schedule time in a database, then uses a cron job to check for due work; with Schedules, an agent creates a schedule that records the request and when to run it, without a separate database and polling job.

A schedule only says when to trigger a task and where to send it; the application still supplies the code that carries out the work. Dynamic schedules are created and managed at runtime through the JS SDK, CLI or API, support one-time and recurring work, and deliver through Queue topics. In the example, an AI SDK tool calls Schedules.create with the task, a future local time and an IANA time zone, targeting the agent-work topic; when due, Vercel uses Queues to deliver the saved request to the app, which reads it, checks the user's current permissions and starts the agent.

Static schedules can still live in project configuration to call private functions or HTTP paths, or send messages to Queue topics. Static schedules sync at deploy time, while dynamic schedules are managed by the application at runtime, covering different cases. The example defines a daily cleanup job as a cron expression with a time zone; Vercel calls that private function directly without exposing it at a public URL and checks that each call comes from the scheduling service, and a Nitro 3 experimental integration runs existing scheduledTasks configuration as private functions.

Vercel Schedules is in public beta and can be used for recurring tasks an application already runs; dynamic schedules support one-time and recurring work and deliver through Queue topics. The documentation says scheduled work can be tested on Preview deployments and in custom environments before production, and Run Schedule can try a task without waiting and show when past runs happened.

The documentation gives no measurements of scheduling precision, throughput or scale, and does not say whether interfaces will change after public beta; in the example, permission checks are done by application code when the task is due, not by the scheduling service.