Practical limitVercel documents a 1 to 15 minute jitter window for Schedules. A job that must execute at one exact second needs a different timing design.
The Vercel Schedules public beta adds static and runtime jobs
Vercel's November 5 changelog says Schedules is available in public beta on all plans. A team can create a recurring schedule in project configuration or create, change and cancel schedules while the application is running.
The runtime mode changes the product design. A user can choose a reminder time or an agent can schedule a follow-up without waiting for a deployment.
Vercel calls Schedules the successor to Cron Jobs. Existing jobs continue to run, so teams can test before migrating critical work.
| Option | Best fit | Important constraint |
|---|---|---|
| Static schedule | App-owned recurring cleanup, refresh or report | Changes with a deployment; no one-time run or payload |
| Dynamic schedule | User reminder, agent follow-up or customer-specific job | Targets a Queue topic and needs runtime permissions |
| Cron Job | Existing public route that is not ready to migrate | UTC, production-only and fewer per-job controls |
Static schedules can call a private function
A static schedule lives in `vercel.json` or build output configuration and becomes active on deployment. It can target an HTTP path, a Vercel Function with no public URL, or a Vercel Queues topic.
A nightly cleanup no longer needs a public route solely so the scheduler can call it. Vercel's Schedules documentation says only its scheduling infrastructure can invoke a private function target.
A path helps during migration because Vercel can call existing route code. Keep authentication and replay protection on every public route.
Dynamic schedules turn timing into a product capability
Dynamic schedules are created through the SDK or CLI and take effect without a deployment. They can run once or recur, carry an optional JSON payload and use namespaces to separate customers or features.
A recruiting assistant can schedule a reminder 48 hours after an interview, then delete it if the interview is cancelled. No infrastructure deployment is required.
The target must be a Queue topic. The application should verify the current user's permission before creating, changing or cancelling a job. A schedule created by an agent still acts with product authority granted by your code.
Queue consumers must tolerate duplicate delivery
Vercel Queues uses at-least-once delivery, which means a message can arrive more than once after a timeout or infrastructure event. A dynamic schedule that charges a card, sends an email or increments a balance must not repeat the effect blindly.
Use a stable operation ID and record completion before applying the side effect again. Setting a report status to “ready” is naturally safer than incrementing a counter. Vercel's Queue concepts explicitly tell consumers to be idempotent.
The schedule API may be a small change while the consumer still needs deduplication, retry-safe writes and failure inspection.
Schedules do not promise exact-minute execution
Vercel documents a jitter window between 1 and 15 minutes. The run should occur inside that window, not necessarily at the first second of the requested minute.
That is acceptable for a daily digest or cleanup. It is a poor fit for an auction close, a legal deadline or another event where one exact timestamp changes the outcome. In those cases, store the deadline as data and enforce it when a request or worker evaluates the state.
Schedules run in production, preview branches and custom environments. Keep preview data separate so a test cannot trigger a production side effect.
The beta adds control, history and a new cost line
Teams can enable, disable or run a schedule on demand without redeploying, then inspect history per schedule in the dashboard or CLI. That makes a failed weekly export easier to operate than a job hidden among general function logs.
Vercel lists Pro and Enterprise pricing at $5 per one million runs and $10 per one million schedule creations. Hobby includes 500 creations and 5,000 runs each month. Queue processing and function execution can add their own usage.
The feature is a public beta, so APIs, behavior and limits can change before general availability. Keep the first migration reversible and avoid coupling a critical business promise to an undocumented behavior.
Test one reversible job before replacing Cron Jobs
Start with a cache refresh, report generation or another job that can safely run twice. Deploy it to preview, run it on demand, observe the history and force a retry so the team can prove idempotency.
Keep Vercel Daemons liveness checks for continuous processes rather than scheduled work. Include schedule ownership, alert response and migration in a website maintenance plan. Teams replacing a larger background system can use the web application modernization guide to map dependencies before moving jobs.
- Choose static for an app-owned recurring job and dynamic for a runtime-created job.
- Use a private function when the task does not need a public route.
- Check permissions before users or agents create dynamic schedules.
- Give every side effect a stable idempotency key.
- Design for the documented 1 to 15 minute timing window.
- Inspect run history, retries and costs before migrating the next job.
- Keep the old Cron Job until the new path is proven and reversible.