← All guides

Your own website returns 403, 429, or 402 — blocked, rate-limited, or suspended?

Updated 23 September 2026 · by Cassian Wei · 4 min read

These three errors confuse owners more than a plain outage does, because the site is provably running: something answered the request. It just answered "no." The status code is a message about who is refusing and why — and each of the three has a completely different fix. We diagnose these in the wild regularly; here is the triage we actually use.

First: find out who answered

# -i shows the response headers; check both http and https, apex and www
curl -si -o /dev/null -D - --connect-timeout 10 https://example.com/ | head -20
curl -si -o /dev/null -D - --connect-timeout 10 http://example.com/ | head -20

Before reading the code, read the Server: header and any vendor headers. A 4xx can come from three different layers, and the fix depends on which one sent it:

  • Your own application — headers look like your normal stack.
  • Your host's front-end — generic Apache/nginx with a branded "suspended" or error page in the body, or a host-specific header (we've seen x-limited: 1 from a shared host's rate limiter).
  • A security/CDN layer — Server: cloudflare, Sucuri, etc. The origin may be fine (or dead) behind it; the edge is what refused you.

Also load the URL in a browser once: 4xx bodies are usually human-readable pages that name the product refusing you ("Account suspended", a bot-check interstitial, a billing notice). That page is half the diagnosis.

403 Forbidden — something is deliberately refusing the request

The most ambiguous of the three. In practice, on your own site, it's one of:

  • Bot/DDoS protection turned up too high. A WAF, "under attack" mode, or bot filter is challenging or refusing traffic — sometimes including your own monitoring, curl, and real visitors on VPNs. Symptom: browsers work (they pass the JS challenge) but tools get 403, or entire networks are blocked. Fix: tune the rule, don't disable the protection.
  • Hosting suspension. Shared hosts often serve a branded 403 "account suspended" page for overdue bills, abuse reports, or resource overuse. The body tells you. Fix: the host's billing/support panel, not your code.
  • Server misconfiguration. Wrong file permissions after a migration, a missing index file with directory listing disabled, or a deny-rule that's broader than intended. Common right after "I rebuilt everything" — we've seen a site whose https had an expired certificate and whose http answered 403, two separate leftovers of one rebuild. Fix: check the web server's error log; it names the file and rule.
  • An IP-scoped block. Only some visitors get the 403 — a country block, a banned range, one overzealous fail2ban entry. Test from a second network or an outside checker before assuming everyone sees it. (More on split symptoms: works for some people but not others.)

429 Too Many Requests — a rate limiter is tripping

Somebody's limiter decided your site is receiving too much traffic — and started refusing everyone, which is how a protection mechanism becomes the outage. On your own site the limiter is nearly always the host's (shared-hosting resource guard) or your CDN's, not your app's. We've watched this live on a magazine site: every request answered 429 with the host's x-limited: 1 header, then the limiter escalated to 403 while the owner was still troubleshooting — the server itself was never down.

  • What triggered it is usually an aggressive crawler, a traffic spike (your post did well somewhere), or a misbehaving plugin hammering your own backend.
  • Fix: find the source in the access log (one IP or user-agent usually dominates), block or slow that, and ask the host to lift the limit. Caching — even a few seconds at a CDN — absorbs most spikes entirely.
  • Don't just wait it out: limiters that trip on their own re-trip on their own. If you can't see what tripped it, that's the thing to fix.

402 Payment Required — a bill went unpaid

Rare enough that people don't believe it's real, but it's exactly what it says: a platform stopped serving your site over billing. Hosting platforms, serverless providers, and site builders use 402 when a subscription lapses or a usage cap is hit on an expired card. The site's code is fine; the account isn't. Fix: the provider's billing dashboard — and afterwards, set a calendar reminder for the card expiry month, because this one always recurs. (Its cousin: the domain expiring, which takes the site down at the DNS layer instead — see domain expiry monitoring.)

Why you're often the last to know

All three of these can serve normal pages to you while refusing others: your IP is whitelisted, your browser passed the challenge yesterday, your page is cached. Meanwhile every new visitor bounces off a 403. An outside monitor closes that gap — a free 60-second-interval check requests your site from the outside like a stranger would, treats 4xx as DOWN, and the alert email includes the status code and response detail, so you start at the right layer instead of restarting a server that was never down.

Watchpup is free uptime & cron monitoring — 1-minute checks, heartbeats, TLS/domain expiry, status pages, alerts everywhere. Sign up, try the live demo, or read more guides.