Wrangler cannot clear Cron Triggers when account is above free-plan limit (10072)

[bhovig]

What happened?

An account has 8 existing Cron Triggers that predate/enforce beyond the current Free-plan limit of 5. I need to reduce the account to 2 triggers. Deploying a Worker with crons = [] fails with error 10072 instead of removing that Worker's existing schedules. The direct API equivalent also fails:

PUT /accounts/<account>/workers/scripts/<script>/schedules
Content-Type: application/json

[]

Response:

10072: This account has reached the Workers Free limit of 5 cron triggers per account.

Because every schedule update is rejected while the account is above the limit, there is no non-destructive way to get back under the limit. Omitting triggers leaves schedules unchanged, and the API exposes no individual schedule-delete operation.

Reproduction

1. Have an account with more than 5 existing triggers (for example, grandfathered schedules).
2. Configure one Worker with:

[triggers]
crons = []

3. Run wrangler deploy.
4. The Worker code uploads, but updating /schedules fails with 10072.

Expected behavior

A schedule update that reduces the account-wide trigger count, especially [], should be allowed even when the current count is above the plan limit. Capacity enforcement should reject only net additions.

Wrangler versions

Observed with Wrangler 4.56.0 and 4.69.0 on Node 22 / macOS. The same failure occurs via the REST API, so this appears to be an API-side limit check rather than Wrangler-only behavior.

Workaround impact

The only apparent workaround is deleting whole Worker scripts, which also destroys script-scoped secrets and creates avoidable downtime. The Cloudflare documentation says crons = [] is the supported way to remove all triggers.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #38

Summary

Deploying a Worker with crons = [] (or calling PUT /schedules with []) fails with error 10072 when the account is already over the Free-plan cron trigger limit, leaving no non-destructive way to get back under the limit.

Classification

• Type: Bug
• Component: Not workers-sdk — Cloudflare Workers API / platform (schedules limit check)
• Severity: Medium
• Has Reproduction: Yes (clear step-by-step repro + raw API repro included)
• Quality: Complete

Findings

• Created: not available (context.json is a single-line file truncated at 2000 chars by the available tooling)
• Author: bhovig (Ben Hovig)
• Version: Wrangler 4.56.0 and 4.69.0, Node 22, macOS
• Labels: could not be read (truncated); first comment author is workers-devprod (Cloudflare automated devprod bot)
• Comments: at least 1 (content not readable due to truncation)

Analysis

• The report is high quality: it includes a precise reproduction, the exact error code (10072), the affected versions, the OS/Node runtime, and the workaround with its downsides.
• The reporter explicitly demonstrates the failure occurs identically against the raw REST API (PUT /accounts/<account>/workers/scripts/<script>/schedules with body [] returns 10072), independent of Wrangler. This strongly indicates a server-side capacity check in the Workers API, not a bug in Wrangler or Miniflare.
• The core complaint is a design flaw in the limit enforcement: the check rejects any schedule update while the account is over-limit, rather than rejecting only net additions. A request that reduces the count (especially to []) should be permitted. This logic lives in the Cloudflare API, which is not part of this repo.
• Wrangler is faithfully forwarding the user's intent (crons = [] → PUT /schedules []) and surfacing the API's error verbatim. There is no code change in workers-sdk that would fix the underlying limit check.
• Caveat: I was unable to read the issue's labels, dates, state, or comment bodies because context.json is a single JSON line longer than 2000 chars and the available read/grep tools truncate at that boundary. If a maintainer sees a comment already redirecting this issue, defer to that. The recommendation below is based on the fully-readable issue body.

Recommendation

Status: CLOSE

Reasoning: The reporter confirms the exact same failure reproduces via the raw Cloudflare REST API with no Wrangler involved, so this is an API-side limit-enforcement issue rather than a workers-sdk tooling bug. There is no fix that can be made in this repository — the schedules endpoint needs to allow updates that reduce the trigger count.

Action: Redirect the reporter to the appropriate channel for the Workers API limit-check behavior (internal Workers platform team / Cloudflare Support), since it cannot be addressed in workers-sdk. If the maintainers can route it internally to the platform team that owns the /schedules endpoint, that would be ideal. Verify labels/comments first (not readable during automated triage) in case someone has already responded.

Suggested Labels: none (labels could not be verified from the truncated context; omitting rather than guessing)

Suggested Comment

Thanks for the detailed report — this is a great write-up. As you noted, the same failure reproduces against the raw REST API (PUT /schedules with [] returning 10072) with no Wrangler involved, so this is a limit-enforcement check on the Workers API side rather than something we can fix in workers-sdk. Wrangler is correctly sending PUT /schedules [] and just surfacing the API's error. The underlying request — that a schedule update which reduces the account-wide trigger count (especially to []) should be allowed even when the account is over the limit — needs to be addressed by the Workers platform team that owns that endpoint. I'd recommend raising this with Cloudflare Support (https://dash.cloudflare.com/?to=/:account/support) so it can be routed to the right team; a maintainer here may also be able to forward it internally. I'm going to close this on the workers-sdk repo since there's no tooling change that would resolve it, but please feel free to reopen or open a new issue if it turns out Wrangler could handle this better (for example, with a clearer error message).

Structured summary (JSON)

{
  "issueNumber": 15194,
  "title": "crons = [] fails with error 10072 when account is over the cron trigger limit, leaving no non-destructive way to reduce triggers",
  "githubUrl": "https://github.com/cloudflare/cf-platform-issues/issues/38",
  "recommendation": "CLOSE",
  "difficulty": "n/a",
  "reasoning": "The reporter confirms the same failure reproduces via the raw Cloudflare REST API with no Wrangler involved, so this is a server-side limit-enforcement issue in the Workers /schedules API rather than a workers-sdk bug. There is no fix possible in this repository.",
  "suggestedAction": "Redirect the reporter to Cloudflare Support / the internal Workers platform team that owns the /schedules limit check; verify labels and existing comments first since they could not be read from the truncated context.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ⚠️ Blocked. Reproduction requires a live Cloudflare account with more than 5 cron triggers plus API credentials, neither of which are available in the sandbox. Error 10072 is an API-side response for that specific account state and cannot be triggered locally.