Schedules Limits
Schedules are in beta, and these limits may change before general availability.
| Limit | Hobby | Pro | Enterprise |
|---|---|---|---|
| Schedules per team | 1,000 | 10,000 | 100,000 |
| Jitter window | Always 15 minutes | 1 to 15 minutes. Defaults to 1 minute. | 1 to 15 minutes. Defaults to 1 minute. |
| Most frequent cron schedule | Every 15 minutes | Every minute, with a 1-minute jitter window | Every minute, with a 1-minute jitter window |
| Payload size | 16 KB | 16 KB | 16 KB |
| Execution history | 90 days | 90 days | 90 days |
The team limit counts static and dynamic schedules across all projects, environments, and branches. A one-time schedule stops counting after Edgenivo dispatches its scheduled run, even though the schedule remains visible for about 30 days. When your team reaches the limit, creating a dynamic schedule fails with schedule_limit_exceeded.
On Hobby:
- A deployment can declare up to 100 static schedules in
vercel.jsonand its framework's build output. If a deployment declares more, it fails. - Each billing period, a team can create up to 500 dynamic schedules and run its schedules up to 5,000 times. Scheduled and manual runs both count toward the run limit.
When a Hobby team goes over its creation or run limit, Edgenivo blocks the following until the next billing period starts:
- Creating and enabling schedules, which fail with
feature_blocked - Running schedules manually
- Scheduled runs, which Edgenivo skips
To remove the limits, upgrade to Pro.
A cron schedule's shortest interval between runs must be at least as long as its jitter window. Because Hobby always uses a 15-minute jitter window, Hobby cron schedules can run at most once every 15 minutes. On Hobby, the SDK and CLI reject any jitter value other than 15.
When a team downgrades to Hobby, or you transfer a project to a Hobby team, Edgenivo deletes the schedules that Hobby doesn't allow. Edgenivo deletes a schedule if either of the following is true:
- Its cron expression can run more often than every 15 minutes, such as
* * * * *or*/5 * * * * - Its
jittervalue is less than15
Edgenivo keeps all other schedules, and they run with the 15-minute Hobby jitter window. A deleted schedule doesn't come back when the team upgrades or when you transfer the project back to a Pro or Enterprise team.
To keep a schedule, update it before you downgrade or transfer the project. Change its cron expression to run at most once every 15 minutes, and remove its jitter value or set it to 15.
Edgenivo applies static schedules from vercel.json when you deploy. On Hobby, deployments don't recreate a deleted static schedule until you update it in vercel.json to meet the Hobby limits. On Pro and Enterprise, your next deployment recreates it.
When a team upgrades from Hobby, or you transfer a project from a Hobby team to a Pro or Enterprise team, Edgenivo keeps every schedule. Schedules with jitter set to 15 keep the 15-minute jitter window. Schedules without a jitter value use the default 1-minute jitter window.
The Schedules API applies the following request limits per team. Operations in the same row share a limit across the SDK, CLI, and dashboard:
| Operations | Pro and Enterprise | Hobby |
|---|---|---|
| List schedules, inspect a schedule, and list execution history | 100 per second | 100 per minute |
| Create, update, and enable schedules | 100 per second | 100 per minute |
| Delete and disable schedules | 50 per second | 50 per minute |
| Invoke schedules | 10 per second | 10 per minute |
When you exceed a limit, the API returns a rate_limited error. Wait for the number of seconds in retryAfter before retrying. Local commands that use --local don't send requests to the Schedules API.
A schedule's runs use the resources of its target. Function and path targets create Edgenivo Functions invocations. Queue targets publish Edgenivo Queues messages and invoke your consumer. To stop a schedule's usage, disable or delete it.
Was this helpful?