Is 509 an official HTTP status code?

No. 509 Bandwidth Limit Exceeded never made it into the HTTP standard — it isn't in RFC 9110 or its predecessors, and IANA lists the code as unassigned in the core registry. It's a convention introduced by an Apache module (mod_bandwidth) and adopted by control panels like cPanel and Plesk to say one specific thing: this account used up the data-transfer quota the host allotted it. That's why nginx, which has no such module, will express the same 'you're over quota' condition as a plain 503 or a custom page instead. So 509 is a hosting-panel signal wearing an HTTP number, not a protocol-level status. Read it as 'the billing meter tripped,' not 'the server broke.'

What's the difference between 509 and 503 or 508?

All three can look like 'the site is down,' but they mean different things. 503 Service Unavailable (RFC 9110) is the generic 'temporarily can't serve' code — overload, maintenance, a restart. 508 on cPanel is CloudLinux LVE throttling: your account blew a CPU, memory, or entry-process cap *right now*, and it clears when load drops. 509 is different from both: the server is healthy and your code is fine — you've simply moved more bytes this billing period than the plan allows, and the host cut you off until the meter resets. 503 is about capacity in the moment, 508 about compute concurrency, 509 about cumulative data transfer over a month. The fix for each lives in a different place.

The 509 cleared on its own — is it really fixed?

Probably not; it just reset. Bandwidth quotas are counted per billing cycle, so a 509 that vanishes on the 1st of the month is the counter rolling over, not the underlying cause going away. If the same account blew its cap once, it will blow it again next cycle unless something changed — either real growth (in which case a bigger plan is the honest answer) or a leak you haven't found: a hotlinked video, an uncompressed image library, a scraper pulling the same large files on a loop, or an unmetered backup job. Treat the reset as a countdown, not a resolution, and go find what's actually eating the transfer.

Views: 13

509 Bandwidth Limit Exceeded: Why the Site Died

509 Bandwidth Limit Exceeded: your host hit its monthly transfer cap, not a server bug. Tell it from 503, find the drain. Free instant check, no sign-up.

Check your domain for this issue now

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

Problem

The site was fine yesterday. Today every page returns 509 Bandwidth Limit Exceeded — often a bare, unstyled page with your host’s branding on it. Nothing in your code changed, the server is up, and other people’s sites on the same box load normally. What happened is mundane and has nothing to do with a bug: your hosting account moved more data this billing period than the plan permits, and the host pulled the plug until the meter resets.

Symptoms

The page reads “Bandwidth Limit Exceeded” with cPanel, Plesk, or your host’s branding — not a framework error or a stack trace.
It appeared abruptly and affects every URL on the domain at once, including static images and the homepage.
Other accounts on the same shared server are unaffected; only your account is blocked.
The timing lines up with the end of a billing cycle, or with a spike — a post that took off, a file that got hotlinked, a crawler that found you.
It frequently “fixes itself” on the first of the month, then comes back weeks later.

What 509 Actually Means

509 is not a real HTTP status code. It’s not in RFC 9110 or any earlier HTTP spec, and the core IANA status-code registry leaves it unassigned. It entered the world through an old Apache module, mod_bandwidth, and got picked up by control panels — cPanel, Plesk, and the like — as a house convention for exactly one situation: this hosting account has exhausted the monthly data-transfer allowance the host sold it.

That origin explains everything confusing about it. Because it’s a panel convention rather than a protocol status, servers without the module never emit it — nginx will show the same over-quota condition as a 503 or a custom error page, so the absence of a 509 doesn’t mean you’re under quota on every stack. And because it’s an account-level billing signal, it hits all your URLs simultaneously and spares your neighbors: the server is healthy, your application is healthy, the meter is what tripped.

This is the key distinction that saves people hours. A 500 or a 503 sends you digging through logs and application code. A 509 is telling you the code is irrelevant — you shipped too many bytes. The question isn’t “what broke,” it’s “what moved that much data, and is it legitimate.”

Top Causes

You genuinely outgrew the plan. Real traffic growth, a launch, a link from somewhere big. The site did its job and the plan is just too small for this month. This is the one case where upgrading is the honest fix rather than a workaround.
Large files served over and over. Video, high-res images, PDFs, downloads. A single 50 MB file pulled a few thousand times is gigabytes. If it’s on the homepage or an autoplay, every visitor drags the whole thing down.
Hotlinking — other people’s pages serving your bytes. Someone embeds your image or video directly from your URL, and now their visitors spend your bandwidth. You see the transfer with none of the traffic in your own analytics.
Bots and scrapers on a loop. Aggressive crawlers, a misbehaving mirror, or a scraper re-downloading the same large assets repeatedly. To the meter it’s indistinguishable from real demand.
A miscounted or unmetered process. Backups copying out over HTTP, a staging job pulling production media, or a CDN misconfigured to pull-through on every request instead of caching. The transfer is real; it’s just not visitors.

Diagnose with DechoNet

HTTP Check reads the exact status line and response headers your origin returns. That confirms two things quickly: whether the 509 is coming straight from your origin (it’ll carry the host’s server signature) and whether it’s constant across requests — a hallmark of an account-level block rather than a transient per-request failure. If the header set and body match a hosting-panel quota page rather than an application error, you’ve ruled out a code bug and can go straight to the bandwidth question.

Resolution Checklist

Open your hosting panel and read the actual bandwidth usage graph. Confirm which resource tripped — this should say transfer/bandwidth for the period, not disk or CPU. Don’t fix the wrong limit.
Check when it reset last and how fast it climbed. A slow, steady climb to the cap means growth; a sudden vertical jump means a single file, a hotlink, or a bot.
Find the heavy URLs. In raw access logs, sort by bytes sent, not by hits — one large asset pulled often beats a million tiny requests.
Kill hotlinking. Add a Referer-based rule (or your panel’s hotlink protection) so other sites can’t serve your large files on your dime.
Put a CDN or object storage in front of static media so images, video, and downloads never come out of your metered hosting bandwidth again. This is the single biggest lever for most 509s.
Block or rate-limit abusive crawlers, and make sure backup/staging jobs aren’t pulling large files over your public HTTP path.
Only after you understand the driver, raise the plan. If it’s real growth, more headroom is honest; if it’s a leak, a bigger cap just delays the next 509.

When to Escalate

If the usage graph shows transfer you can’t account for — far more than your analytics or logs explain — ask the host to break down the bytes by day and path. A miscount, a compromised account serving spam files, or a runaway process can inflate the meter, and only the host has the full picture.
If you’ve moved static assets to a CDN, killed hotlinking, and blocked bad bots but still hit the cap every cycle, the site has genuinely outgrown shared hosting. That’s a capacity conversation — a larger plan, a VPS, or unmetered egress — not another config tweak.