HTTP 4xx response

Your server is reachable and replying, but it's rejecting the request. DomainDash shows the site as Down because it expected a 2xx response and got a 4xx instead.

Symptom

• DomainDash marks the uptime check as Down with error code http_4xx
• Running curl -I https://example.com returns a 4xx status code in the first line of the response (e.g. HTTP/2 403, HTTP/2 404, HTTP/2 429)
• Visitors may see a "Not Found", "Forbidden", or "Too Many Requests" error page

What it means

A 4xx response code is a "client error" in Hypertext Transfer Protocol (HTTP): the server understood the request but won't or can't process it. Unlike 5xx errors (which indicate a server-side problem), a 4xx means the server itself is working fine — something about this particular request isn't being accepted.

By default, DomainDash treats a successful (2xx) or redirect (3xx) response as healthy, and any 4xx as a Down status, because from a visitor's perspective, the page isn't accessible. The exact code tells you precisely why, so you can go straight to the fix instead of guessing.

Common causes

• 401 Unauthorised — the URL DomainDash is checking requires authentication. The checker is being sent to a login-protected page and can't pass credentials.
• 403 Forbidden — a web application firewall (WAF), Cloudflare bot-detection, or IP allowlist is blocking the checker's request.
• 404 Not Found — the URL has moved, was deleted, or was never correct. A recent deploy may have changed the route.
• 410 Gone — the page was intentionally removed. The target URL needs updating.
• 429 Too Many Requests — rate-limiting is treating the checker as a high-frequency client and throttling it.

How to fix

1. Identify the exact status code. Run:

   curl -I https://example.com

   The status code on the first line tells you which cause applies.

2. Check whether the target URL is correct. Open DomainDash and look at the URL configured for this site. The best URL to check is a publicly accessible endpoint that always returns 200: typically the site root (/), a dedicated health-check path (/health or /ping), or a static asset. If the current URL requires login or has moved, update it in the site's settings.

3. For 403, check WAF and bot-detection rules. A firewall may be blocking the checker's HTTP signature. Check your WAF (Cloudflare, AWS WAF, Sucuri) access logs to find the triggered rule. You can test whether the User-Agent is the issue:

   curl -I -A "Mozilla/5.0 (compatible)" https://example.com

   If that returns 200 but a plain curl request returns 403, the WAF is flagging curl's default User-Agent. The most reliable fix is to allow DomainDash's checks through by matching on the checker's User-Agent in your WAF, since checks come from rotating cloud IPs rather than a fixed range. Your WAF access logs will show which rule is blocking the request.

4. For 429, check rate-limiting rules. A 429 means the checker is being throttled. Check your Cloudflare Rate Limiting rules, your application's rate-limiter middleware, or your web server's throttle config. Either raise the rate-limit threshold so the checker's requests aren't throttled, or exempt DomainDash's checks by matching the checker's User-Agent.

5. For 404, verify the application route. Check your application's routing config and confirm the path exists:

   curl -I https://example.com/your-path

   If a recent deploy renamed or removed the route, update the target URL in DomainDash to match the current correct path.

6. Verify the fix. Run curl -I https://example.com and confirm the response is now 2xx.

How to verify

Confirm the page is welcoming requests again, not turning them away:

1. Run curl -I https://example.com. The response should start with HTTP/2 200 (or another 2xx code).
2. Open the site in a fresh browser window. It should load normally.
3. Open the site in DomainDash. It re-checks on its normal schedule, so once your fix is live the status returns to Healthy on its own within a check cycle, with nothing to click.

Related

• HTTP 5xx response — if the server is returning a server-error code instead
• Site is down — if you're not sure which uptime issue you have
• Uptime — how DomainDash runs uptime checks
• Site settings — where to update the path being checked and the expected response code