How is Error 1027 different from Error 1015?

They're two different Free-plan limits on Cloudflare Workers. 1015 is the burst rate limit — 1,000 requests per minute — and it clears the moment traffic drops. 1027 is the daily request limit: 100,000 Worker invocations in a UTC day, and once you hit it the Worker stays disabled until the counter resets at 00:00 UTC. So 1015 is a short spike you ride out in a minute; 1027 is a wall you hit for the rest of the day.

Why does 1027 come back at the same time every day?

Because the daily counter resets at midnight UTC, not local midnight. If your site dies in the late afternoon and comes back in the small hours, that pattern is the tell: you're burning through 100,000 Worker requests before the UTC day is over. The fix isn't to wait it out every day — it's to either cut the request volume or move off the Free plan's daily cap.

I don't run a Worker on purpose. Why am I seeing 1027?

Two common surprises. On Cloudflare Pages, every Pages Functions invocation counts against the same limit. And a Worker placed in front of a whole zone counts every request it sees — including static assets and, very often, bot traffic — so a site that looks low-traffic in analytics can still cross 100,000 raw requests a day. Check what's actually routed through the Worker before assuming the number is wrong.

Views: 6

Error 1027 Cloudflare: Worker Daily Request Limit

Error 1027 means a Cloudflare Worker hit the Free plan's 100,000/day request cap. Fix it in 4 checks: status, source, fail-open, upgrade. Free instant check.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your Cloudflare-hosted site or Worker starts serving a Cloudflare-branded page reading “This website has been temporarily rate limited. You cannot access this site because the owner has reached their plan limits,” with error code 1027. It usually appears later in the day and clears overnight. This isn’t your origin server going down and it isn’t a code crash — a Worker on the Free plan has spent its daily request budget, and Cloudflare has switched it off until the day rolls over.

Symptoms

Visitors see a Cloudflare error page with 1027 and text about the site being “temporarily rate limited” and the owner reaching their “plan limits.”
It appears part-way through the day and the site comes back on its own after 00:00 UTC — roughly the same clock time every day.
The Cloudflare dashboard shows your Workers requests for the day at or near 100,000.
Your origin server is healthy — you can reach it directly, and it’s not logging the failed requests, because the edge is answering before they get there.
It started after a traffic bump, a new bot crawling you, or a change that put a Worker in front of more of your routes.

What Error 1027 Actually Means

Cloudflare’s Workers Free plan includes 100,000 requests per UTC day, plus a burst limit of 1,000 requests per minute. Error 1027 is what you get when the daily one runs out. Every request routed through your Worker counts against that 100,000, and when the total crosses it, Cloudflare stops running the Worker for the rest of the UTC day and serves the 1027 page instead. At 00:00 UTC the counter resets and the site returns as if nothing happened.

That “as if nothing happened” is exactly why 1027 is so easy to misdiagnose. It self-heals every night, so it looks like an intermittent, spooky outage rather than a hard limit you’re walking into on schedule. The reset is on UTC, not your local time, which is why the outage window drifts relative to your business hours and doesn’t line up with anything in your own logs.

It’s worth separating 1027 from its neighbors, because the fixes are different. 1015 is the per-minute burst limit — a brief spike, gone in a minute. 1101 means your Worker threw an unhandled exception (a code bug, with a stack trace in wrangler tail). 1102 means a single invocation blew past its CPU or memory budget. 1027 is none of those: your code is fine, each request is fine, you’ve simply run too many of them in one day on a plan that caps the count.

Top 3 Causes

The Worker fronts your whole zone, so it counts everything. A Worker on a broad route (example.com/*) runs for every request it matches — HTML, but also images, scripts, fonts, and favicons. A handful of real visitors loading pages with 30 assets each adds up to 100,000 requests faster than your visitor count suggests. The tell: your analytics show modest page views but the Workers request graph is an order of magnitude higher.
Bots and crawlers, not humans, are spending the budget. Aggressive scrapers, a misbehaving uptime monitor, or an AI crawler hitting every URL can burn six figures of requests a day while your real traffic is flat. The tell: the request spike doesn’t match any campaign or launch, and the source IPs or user-agents in your logs aren’t your users.
A Worker making its own subrequests, or Pages Functions volume. A Worker that calls out to APIs, or fans one incoming request into several, multiplies the count. On Cloudflare Pages, every Functions invocation draws from the same daily pool. The tell: request volume is a clean multiple of your actual traffic, or you’re on Pages and didn’t realize Functions counted.

Diagnose with DechoNet

HTTP Header Check fetches the URL and shows you exactly what Cloudflare is returning — the 1027 error body and the cf-ray header — which confirms the block is happening at Cloudflare’s edge on the account’s plan limit, not at your origin. If the same check succeeds again after 00:00 UTC, you’ve confirmed the daily-reset pattern.
IP Lookup helps you check the source addresses hammering the Worker (from your Cloudflare logs) against their network and reputation, so you can tell a runaway bot from legitimate growth before you decide whether to block or to upgrade.

Resolution Checklist

Confirm the error code is 1027 (daily limit), not 1015 (per-minute burst), 1101 (Worker exception), or 1102 (per-request resource limit) — each points at a different fix.
Check your Workers request count for the current UTC day in the Cloudflare dashboard and confirm it’s at or above 100,000.
Immediate mitigation: in the dashboard, set the affected route to fail open so requests bypass the Worker and go to your origin instead of hitting the 1027 wall.
Find what’s spending the budget — compare Worker request volume to real page views, and look for a broad /* route counting static assets, subrequest fan-out, or Pages Functions.
If it’s abuse, block or challenge the offending IPs/user-agents; if it’s a broad route, narrow the Worker’s matches or cache responses so fewer requests reach it.
If it’s legitimate traffic, move off the cap: the Workers Paid plan ($5/month) removes the daily limit and bills per request beyond the included allotment.

When to Escalate

If your Worker request count sits far above your actual traffic and you can’t find the source, pull the Workers logs and analytics for the offending window before opening a ticket — Cloudflare support can help read the request breakdown, but only with the timestamps and Ray IDs in hand.
If you’ve upgraded to Paid and still see 1027, the plan change may not have applied to the right account or the Worker may be on a different account than you think — verify which account owns the route, because 1027 after upgrading is almost always a billing-scope mismatch, not a limit you’re genuinely exceeding.