workerd error: free tier daily request limit exceeded, 403 on new requests

TL;DR: Something is making far more requests than you think. Check the dashboard for the traffic spike, find the source (a runaway cron, a polling loop, a hot asset), cache at the edge to absorb it, and move to a paid plan if the traffic is legitimate. The daily quota resets, but the spike will just burn it again tomorrow.

workerd error: free tier daily request limit exceeded, 403 on new requests

1. Confirm the quota is the cause. Open the Workers dashboard and check the request count for the day.

Expected: the count sits at the free-plan daily cap and 403s started when it hit the ceiling.

1. Find what is generating the traffic. Look at the analytics breakdown by path, and check scheduled handlers and any client polling loops.

Expected: one or two paths or a cron trigger account for most of the volume.

1. Kill the accidental sources first. A cron running every minute that fans out, a health check polling every second, or a client retry loop can burn the quota alone.

Expected: request volume drops sharply after the runaway source is fixed.

1. Cache what is cacheable. Put Cache API or edge caching in front of repeated identical GETs so they stop counting as full worker executions.

Expected: repeat traffic for the same content stops consuming quota.

1. If the traffic is real and valuable, upgrade the plan. Paid plans raise the included requests far above the free cap.

Expected: 403s stop and headroom returns.

1. Set up an alert on daily request volume so the next spike pages you before the quota is gone.

Expected: you get warned at 70 to 80 percent of quota, not at 100.

Use this when

• new requests 403 in the afternoon or evening and work again the next morning
• the dashboard shows request volume pinned at the free-plan cap
• traffic spiked after a launch, a cron change, or a client deploy
• you need to decide between cutting traffic and upgrading the plan

Not for this skill when

• 403s happen at all hours including right after midnight UTC (that is not quota exhaustion)
• the 403 comes with a rate-limit or WAF message instead of the quota message
• a single endpoint 403s while others work (that is routing or auth)
• you are on a paid plan and still seeing quota 403s (check for a different cap, like subrequests)

Variant phrasings

• Cloudflare Workers free plan limit 403
• daily request limit exceeded workers
• worker 403 after too many requests free tier
• workers.dev quota exceeded 403
• free tier 100k requests limit hit

Why it happens

The free plan includes a fixed number of requests per day. Every execution counts, including cron triggers, polling loops, retries, and bot traffic. Quotas reset on a daily boundary, which is why the failure is time-of-day shaped: fine in the morning, 403s in the evening. Most cases are not real user growth but accidental traffic, which is why step 2 and 3 come before paying.

Edge cases

• Subrequests do not count against the daily request quota the way top-level requests do, but retries and cron triggers do. Audit all entry points.
• A DDoS-shaped spike can burn the quota in minutes. Rate limiting and bot management matter more than caching in that case.
• The dashboard can lag real usage by minutes. If 403s persist right after the reset boundary, wait a few minutes before assuming a new problem.
• Upgrading mid-spike does not refund the burned quota. Fix the runaway source first or the paid quota burns too.
• workers.dev subdomains share the account quota. A side project on workers.dev can starve the production worker.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RayjchlIj36K9OmykHQHTA