On 4 November 2026 Vercel announced Schedules, now in public beta. The product is interesting, but the sentence Vercel used to explain why it exists is more useful to anyone who runs scheduled jobs. Describing ordinary cron jobs, the post says: "You define them once in code and then can update them by editing their config and redeploying."
That sentence describes one place a schedule can live: the repository. There are at least two others. Where you put a schedule decides who can change it, how fast, and what you can see afterwards. This article compares the three and the trade-off each one makes. It is not about price; our earlier comparison with Vercel covered how the bills are built. This one is about when a schedule's definition can change.
What Vercel shipped
Vercel Schedules has two halves. In Vercel's words, "Static schedules keep the timing in vercel.json or Build Output API configuration and sync when you deploy," while "Dynamic schedules let your app create and manage schedules through the JS SDK, CLI, or API as it runs. They support one-time and recurring work through Queue topics." The stated goal is to let "agents and applications to create, change, or cancel one-time and recurring schedules through code, without redeploying."
Two details are worth knowing before you read the example configuration. The static example marks its function with "experimentalTriggers": [{ "type": "schedule/v1beta" }], and Vercel describes its Nitro 3 support as an "experimental integration". This is a beta, and the configuration format says so.
Place one: the schedule lives in the repository
This is the model Vercel's sentence describes: a schedule written in a config file next to the code, applied when you deploy.
- What you get: the schedule goes through the same review as the code. A change to when the database backup runs shows up in a pull request, can be diffed, and rolls back with the deploy. Nothing at runtime can quietly rewrite it.
- What it costs: changing a time means a deploy. If your deploy path is blocked, for example by a failing test or a frozen release, the schedule change is blocked with it. And a schedule that belongs to one customer or one request cannot be written into a config file at all.
Place two: the schedule lives in the platform
The classic crontab on a server works this way, and so does DeployBase. Cron jobs are added and removed from the cron section of each app's page in the dashboard, or through our API with an API token created in dashboard Settings. The change is written to the server's cron straight away; no deploy is involved. On plans that include SSH (Pro and above), crontab -e works too, and those entries appear in the same list. Schedules are standard five-field cron expressions. There are no one-time jobs.
- What you get: you can move a nightly job from 02:00 to 04:00 in seconds, even when you cannot deploy.
- What it costs: the schedule is not in your repository, so nobody reviews it, and it does not roll back when the code does. DeployBase does not keep a history of cron changes either. That can bite after a refactor. If a deploy renames
scripts/nightly.js, the cron entry still calls the old path, and nothing in the deploy tells you.
There is a common way to get most of the first model's benefits from the second: keep the timing in code and give the platform a single entry that never changes. Laravel's scheduler is the familiar example. One cron entry runs php artisan schedule:run every minute, and every real schedule is defined in the application, reviewed and deployed with it. The same pattern works in any language: one minute-by-minute entry that runs a script, and a script that decides what is due.
Place three: the schedule lives in the application, at runtime
This is Vercel's dynamic half, and it covers a case the other two cannot serve well. Vercel's example is an agent asked, "Tomorrow morning, summarize the top five stories on Hacker News." The schedule is created by a user's request, belongs to that user, and runs once.
Vercel describes the usual way to do this today: "storing the request and its schedule time in a database, then using a cron job to check for work that is due." That is exactly what you would build on a platform with only cron: a table of due tasks and one cron entry that checks it every minute. It works, but you own the table, the polling, the retries and the cleanup. Vercel's pitch is that the platform holds the schedule and delivers it to your code when it is due.
- What you get: per-user and one-time schedules without your own polling table.
- What it costs: the schedules are created by running code, so review happens on the code that creates them, not on each schedule. Your repository no longer tells you what will run tonight; the platform's list does.
Choosing
- Fixed operational jobs (backups, sync, cleanup): keep the definition in code. Either a repo config, or a single platform cron that runs your own scheduler.
- Jobs you may need to move in a hurry: a platform-stored cron changes without a deploy. Write down every change yourself, because the platform may not keep a record.
- Schedules created by users or agents: these need runtime scheduling, either a platform feature built for it or your own table with a polling cron.
Whichever you pick, check one more setting: the time zone a schedule runs in. Vercel's example puts it in the configuration ("timezone": "America/New_York"). A classic crontab uses the clock of whatever machine runs it, which can differ between two crons on the same platform and shifts with daylight saving time where the zone observes it.
If you are new to the cron syntax itself, our guide to Linux cron jobs covers it.
Sources: Vercel, "Introducing Vercel Schedules", Elliot Dauber, published 4 November 2026, read in full 6 November 2026. DeployBase behaviour checked against our own code and server configuration on 6 November 2026.