cPanel Bandwidth Limit Exceeded: Find What's Using It

· 6 min read · 11 views · Getwebup

Your site goes down, WHM shows a red "bandwidth limit exceeded" flag, and the account gets throttled or suspended until the next billing cycle. Nothing changed in your code - your visitors, or something impersonating them, just pulled more data than your plan allows. Here's how to find out what actually ate the bandwidth and stop it from happening again.

What "bandwidth exceeded" actually means

Bandwidth (also called data transfer) is different from disk quota. Disk quota is how much you're storing. Bandwidth is how much data leaves your account over a billing period - every page load, every image, every file download, every email attachment sent. cPanel plans on shared and reseller hosting usually cap this monthly; VPS plans cap it too, just at a much higher ceiling.

When you cross the limit, one of two things happens depending on how the host configured it:

  • The account gets suspended outright, showing a "bandwidth limit exceeded" page instead of your site, until the next cycle or until you're upgraded.
  • The account keeps running but the host emails a warning, and you get billed for the overage.

Either way, the fix is the same: find what's actually consuming the transfer, cut the waste, then decide whether you need a bigger plan or just better caching.

Step 1: Check your real usage

Don't guess - look at the numbers first. In cPanel, go to Statistics (left sidebar) and check the Bandwidth widget, or open Metrics → Bandwidth for a monthly breakdown by HTTP, FTP, and email. If you're a reseller or have WHM access, WHM → List Accounts shows bandwidth used per account against its cap.

Those graphs tell you how much, but not what. For that, pull the raw access logs. SSH in and run:

cd ~/access-logs
ls -la
gunzip -c yourdomain.com-Jul-2026.gz | awk '{sum+=$10} END {print sum/1024/1024 " MB served"}'

To find which URLs or files are the heaviest, sort by hit count and by response size:

# top 20 most-requested URLs
awk '{print $7}' yourdomain.com | sort | uniq -c | sort -rn | head -20

# top 20 IPs by request volume
awk '{print $1}' yourdomain.com | sort | uniq -c | sort -rn | head -20

If AWStats or Webalizer is enabled for the domain (cPanel → Metrics), it's usually faster than reading raw logs - it already breaks traffic down by file type, referring site, and visitor country.

Step 2: The usual suspects

Bandwidth overages almost always trace back to one of these:

CauseHow to spot itFix
Hotlinked images/videosRequests for your media files with a referrer from a domain you don't ownEnable cPanel Hotlink Protection; serve media through a CDN with token auth for large files
Bots and scrapersOne IP or user-agent hammering hundreds of pages per minute in the access logBlock the IP/ASN in the firewall; add a robots.txt crawl-delay; challenge with Cloudflare
Unoptimized images/videoTop-requested URLs are large, uncompressed uploadsCompress and resize on upload; move video off-server to YouTube/Vimeo/S3
No caching layerEvery page view regenerates the full page instead of serving a cached copyTurn on a page cache plugin or LiteSpeed Cache; put Cloudflare or another CDN in front
Direct file downloadsLarge PDFs, zips, or backups served straight from public_htmlHost large downloads externally (S3, Google Drive) and link out instead
A DDoS or brute-force waveSudden spike in requests to wp-login.php, xmlrpc.php, or a single endpointRate-limit or block at the firewall/Cloudflare level; disable XML-RPC if unused

In our support queue, hotlinking and bots are the two most common causes on shared hosting - a single image linked from a high-traffic forum or a scraper crawling every product page on a WooCommerce store can burn through a month's allowance in days.

Step 3: Get back online now

If the account is actively suspended, you need a quick fix before the deeper cleanup:

  1. Contact your host to confirm the exact cause and ask for a temporary bandwidth bump - most providers will grant one call while you fix the underlying issue.
  2. Put the site behind Cloudflare (free plan is fine) immediately. Cached static assets get served from Cloudflare's edge instead of your account, which cuts outbound transfer dramatically without touching your code.
  3. If a specific IP or bot is the obvious cause, block it right away in cPanel's IP Blocker or via .htaccess:
<RequireAll>
    Require all granted
    Require not ip 203.0.113.44
</RequireAll>

Step 4: Prevent it from recurring

  • Enable Hotlink Protection in cPanel so other sites can't embed your images and burn your transfer for their traffic.
  • Add a CDN (Cloudflare, BunnyCDN, or similar) so repeat visitors pull assets from the edge, not your origin.
  • Set image and video limits - compress on upload with a plugin like ShortPixel, and never host video files directly; embed from YouTube/Vimeo instead.
  • Turn on page caching so PHP doesn't regenerate the same page for every visitor.
  • Watch the trend, not just the total - check Metrics → Bandwidth monthly so a slow creep doesn't turn into a surprise suspension.
  • If you manage WHM for clients, set a sane bwlimit per package and enable the low-bandwidth warning email in WHM → Tweak Settings so accounts get flagged before they hit the wall, not after.

If none of this is enough and the traffic is legitimate - your site actually grew - that's a plan upgrade, not a bug. A VPS with a higher transfer cap or a CDN-fronted setup will scale a lot further than tightening a shared hosting allowance ever will.

Quick reference

SymptomLikely causeFirst thing to check
Slow, gradual creep toward the limitOrganic traffic growth, uncached pagesMetrics → Bandwidth trend over 3 months
Sudden spike overnightBot, scraper, or hotlinkingRaw access logs sorted by IP and URL
Spike tied to one file/pageA viral post, hotlinked image, or large downloadAWStats "Files" report
Repeated hits on login/xmlrpcBrute-force or credential-stuffing attemptaccess-logs grep for wp-login.php/xmlrpc.php

Getwebup hosting plans include AWStats and Webalizer by default, so you never have to grep raw logs unless you want the extra detail - but when a suspension is already blocking your site, the SSH commands above are the fastest way to a real answer.

Questions people actually ask