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 or 3xx response and got a 4xx.

Symptom

• DomainDash shows the site as Down. On the Uptime page, the latest Check history row shows the status code, for example HTTP 404
• 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 is working and won't accept this particular request.

The Expected response setting defaults to 200. With 200 selected, DomainDash treats any successful (2xx) or redirect (3xx) response as healthy. Any other choice (301, for example) must match exactly. A 4xx response shows the site as Down unless it is the Expected response you chose, because from a visitor's perspective the page isn't accessible. The exact code tells you why the request was rejected.

Common causes

• 401 Unauthorised — the URL DomainDash is checking requires authentication. The URL points at a login-protected page, and the checker 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 the Path on the Uptime tab of 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. Allow DomainDash's checks through by matching on the checker's User-Agent in your WAF. It starts with DomainDash/. Checks don't come from fixed IP addresses, so an IP allowlist won't work.

4. For 429, check rate-limiting rules. A 429 means your server or CDN is rate-limiting the DomainDash checker. This often happens when the check frequency is high and the rate-limit threshold is low. 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 or 3xx.

How to verify

Confirm the page returns a healthy response:

1. Run curl -I https://example.com. The response should start with HTTP/2 200 (or another 2xx or 3xx code).
2. Open the site in a fresh browser window. It should load normally.
3. Open the site in DomainDash. After the first passing check the site page header reads Recovering, and once recovery is confirmed it reads Healthy. If uptime for the selected timeframe (24 hours by default) is under 97%, it reads Unstable until the figure recovers.

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 and Expected response on the Uptime tab