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 expects a 2xx response from the URL being checked. Any 4xx response triggers a Down status, because from a visitor's perspective, the page isn't accessible. The exact code tells you precisely why.

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

Identify the exact status code. Run:
bash
```
curl -I https://example.com
```
The status code on the first line tells you which cause applies.
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.
For 403 — check WAF and bot-detection rules. A firewall may be blocking the checker's IP range or 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:
bash
```
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 clean fix is to allowlist DomainDash's checker IP ranges in your WAF settings — these are listed in your site's settings page under "Uptime checker IPs".
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 threshold for the checker IP range, or add DomainDash's IPs to an allowlist.
For 404 — verify the application route. Check your application's routing config and confirm the path exists:
bash
```
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.
Verify the fix. Run curl -I https://example.com and confirm the response is now 2xx.

How to verify

After fixing:

Run curl -I https://example.com — the response should start with HTTP/2 200 (or another 2xx code).
Open the site in a fresh browser window — it should load normally.
In DomainDash, go to the site's uptime tab and click "Check now". Status should flip from Down to Healthy.

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 target URL and configure expected status codes

HTTP 4xx response ​

Symptom ​

What it means ​

Common causes ​

How to fix ​

How to verify ​

Related ​