HTTP 403 means the website or an upstream security service received the request but refused to allow it. The site is reachable at the network level, but Uptime Basics cannot treat the protected resource as available.
Uptime Basics labels this diagnosis Blocked and treats the check as failed unless 403 is explicitly configured as an accepted status code.
A new monitor that returns an unaccepted 403 cannot pass initial validation. An existing monitor can begin returning 403 after a firewall, CDN, WAF, bot-management, geographic, or application policy changes.
Identify where the 403 is generated
- Open Detailed Logs and confirm the HTTP code and timestamp.
- Review Failure Diagnosis and regional Confirmation.
- Compare response behavior for the exact monitored URL, not only the homepage.
- Check CDN, WAF, reverse-proxy, web-server, and application security logs.
- Look for the request in each layer to identify where it was rejected.
The style or headers of the 403 page can sometimes identify the provider, but server-side logs are more reliable.
Common causes
WAF or bot-management rule
Automated requests can be blocked by bot scores, browser challenges, managed rules, request-rate policies, or missing browser behavior. Uptime Basics performs an HTTP request; it does not execute JavaScript challenges or solve CAPTCHAs.
Create an exception only for a safe health endpoint or a narrow monitoring rule. Do not disable broad security controls for the whole website.
Geographic or regional restriction
The primary and confirmation checks run from different regions. A rule that permits your location but denies a monitoring region can make the website work for you while it fails monitoring.
Review the Confirmation column to determine which regions were rejected. Decide whether customers in those locations should also have access before changing a geographic rule.
Missing custom header
A protected health endpoint can require a dedicated custom header. Add the required name and value under Advanced Request Options.
Custom Authorization, Cookie, Host, and connection-sensitive headers are blocked. Use Basic Authentication for standard HTTP Basic credentials. Saved secret values are encrypted and hidden after saving.
File, directory, or application permissions
The web server may deny the requested path because of filesystem permissions, route authorization, hotlink protection, deny rules, or an application role check. Test the exact path and review server configuration.
CDN and origin disagree
The CDN may allow the request while the origin denies it, or the reverse. Confirm the hostname, origin host header configuration, TLS settings, and security policy at every layer.
Rate or abuse protection
Some providers use 403 instead of 429 for automated or repeated requests. Review request-frequency controls. If the target intentionally limits monitoring frequency, select a longer supported interval and use a purpose-built health endpoint.
Safer ways to permit monitoring
- Create a lightweight health endpoint that does not expose private data.
- Require a dedicated custom header with a rotatable, least-privilege value.
- Exempt only that path and the minimum necessary rule condition.
- Keep normal authentication and bot protection on customer-facing areas.
- Log access to the health endpoint and rotate its key if exposed.
Do not rely on an unrestricted hidden URL as the only protection, and do not place its secret in a query string.
Should you accept HTTP 403?
Accepting 403 only proves that the rejecting layer is responding. It does not prove the monitored website or application is available to users.
Use an accepted 403 only for a specialized endpoint where that exact response is the documented healthy outcome. For a normal website, fix the access rule or monitor a suitable health endpoint instead.
Once 403 is accepted, future 403 responses count as Up and no Blocked diagnosis is recorded for those checks.
After correcting the rule
Save any required monitor setting and allow the next check cycle to run. A successful result resets failure confirmation or resolves the incident. The dashboard may need one additional automatic refresh to show recovery.
Keep the existing monitor so the logs and incident history remain available for review.
When to contact Support
Contact Support if your security logs show that the monitoring request should be allowed but Uptime Basics continues to receive 403.
Include the monitor name, URL, timestamps, affected regions, security provider, and names of relevant custom headers. Do not include header values, passwords, firewall credentials, session cookies, or private keys.