Vercel Schedules enters public beta as timezone-aware successor to Cron Jobs

Vercel ships Schedules, the Cron Jobs successor

According to a dev.to write-up, Vercel introduced Schedules on 4 November 2026 and declared it a public beta a day later. Schedules is positioned as the successor to Cron Jobs, but the transition is voluntary: existing cron configurations keep running and Vercel provides a migration guide rather than forcing a cutover.

Cron Jobs on Vercel were effectively a path plus a cron expression evaluated in UTC. Schedules keeps static configuration in vercel.json (or the Build Output API) and adds a runtime layer through the @vercel/schedules SDK, CLI and API, so schedules can be created, cancelled, toggled or invoked on demand without a redeploy.

What is new

Per the dev.to comparison, the meaningful differences are:

• Time zones. Each schedule accepts an IANA time zone; crons were UTC-only.
• Private targets. A schedule can invoke a function through an experimentalTriggers entry of type schedule/v1beta. That function has no public URL and can only be called by the scheduler, unlike cron path hits, which are publicly reachable unless you add protection such as a shared secret.
• HTTP method. Path-based schedules default to POST, whereas Cron Jobs issued GET requests. Handlers ported as-is need requestMethod set to GET.
• Preview safety. New static schedules start inactive on Preview deployments, so a branch push does not accidentally trigger production chores.
• Dynamic scheduling. Runtime-created one-off or recurring schedules target Queue topics and can carry a payload, which the article frames as a replacement for polling patterns, for example scheduling an agent follow-up hours ahead without holding a function open.

Delivery is at-least-once: duplicates are possible, there are no automatic retries for function or path targets (retries apply on the queue side), and handlers should deduplicate on the execution ID. Payloads are capped at 16 KB and execution history is retained for 90 days.

Pricing and limits

The figures below come from Vercel's changelog and limits pages as read by the dev.to author on 6 November 2026, and the article stresses they are a snapshot rather than a billing guarantee:

• Pro and Enterprise are metered at $5 per 1 million runs and $10 per 1 million schedule creations beyond plan inclusion.
• Hobby includes 500 creations and 5,000 runs per month; past that, both are blocked until the next billing period.
• Team caps are 1,000 schedules on Hobby, 10,000 on Pro and 100,000 on Enterprise, with up to 100 static schedules per Hobby deployment.
• Hobby schedules fire at most every 15 minutes inside a 15-minute jitter window. Pro and Enterprise default to a 1-minute window, configurable between 1 and 15 minutes.
• For comparison, Hobby Cron Jobs run at most once per day with hour precision, Pro and Enterprise crons can run as often as once per minute, and crons continue to bill as function invocations.

Migrating without firing twice

The dev.to checklist recommends swapping the crons array for named schedules entries in a single deploy, setting requestMethod to GET where handlers still expect it, and deleting the cron entries in the same change — keeping both configured means the same job executes twice. After deploying, verify the schedule in the dashboard's Schedules tab and trigger it manually via the CLI, then optionally move path targets to private functions to shrink the exposed surface.

Why it matters

Schedules removes several long-standing serverless annoyances at once: timezone-aware triggers without UTC arithmetic, private invocation instead of publicly reachable endpoints guarded by secrets, and runtime control that no longer rides on deploys. The metered pricing also shifts the cost conversation from function invocation billing to per-run and per-creation charges, so high-frequency workloads should model both. The migration itself is mostly a config reshape, but the POST-by-default switch is a silent breaker for ported GET handlers, and at-least-once delivery makes idempotent handlers a hard requirement rather than good practice.