A website can work in your browser while rejecting or delaying independent HTTP monitoring. Firewalls, CDNs, WAFs, bot-management services, geographic rules, rate limits, and application access policies can all create this difference.
Uptime Basics reports the response it receives. It does not bypass access controls, execute JavaScript challenges, solve CAPTCHAs, or reuse your browser session.
Signs that monitoring is being blocked
- HTTP 403 with a Blocked diagnosis;
- HTTP 429 with a Rate limited diagnosis;
- HTTP 401 from a resource that requires authentication;
- repeated timeouts with no HTTP response;
- different outcomes between confirmation regions;
- a branded security-provider challenge or denial page; or
- server logs that show the request being rejected before it reaches the application.
Some browser challenges return HTTP 200. Availability checks evaluate the HTTP result, not page content or JavaScript behavior, so a challenge page that returns 200 can appear Up. A dedicated health endpoint provides a more reliable signal.
Identify the rejecting layer
- Open Detailed Logs and note the timestamp, HTTP code, diagnosis, and regional Confirmation.
- Check CDN, WAF, load balancer, reverse-proxy, web-server, and application logs.
- Search for the exact monitored path and time.
- Compare the action, rule name, geographic decision, method, and rate-limit group.
- Confirm whether the request reached the origin.
If the request is absent from origin logs, investigate the edge and security layers first.
Permit monitoring without weakening the website
The recommended design is a lightweight health endpoint with a narrowly scoped access rule.
- Allow only the health path and the GET or HEAD method it needs.
- Return no customer data, stack traces, environment details, or secrets.
- Use a dedicated custom header or HTTP Basic Authentication when appropriate.
- Keep normal bot protection and authentication on customer-facing pages.
- Log health-endpoint access and rotate any dedicated secret if exposed.
- Test the rule from every region shown in the confirmation results.
Do not disable a WAF, CDN security policy, rate limit, or authentication requirement for the entire website just to make a monitor pass.
Custom headers and authentication
You can configure up to 10 supported custom request headers. Connection-sensitive headers, Cookie, Host, and custom Authorization headers are blocked.
Use the monitor's Basic Authentication option for standard HTTP Basic credentials. Uptime Basics does not complete interactive sign-in forms or maintain a browser session.
Do not place passwords, API keys, bearer tokens, or private information in the monitored URL. Saved supported request secrets are encrypted and are not returned in plaintext.
Check regional policy
Monitoring failures from one region can indicate a regional firewall, geographic restriction, edge problem, or route-specific bot score. Failures confirmed from at least two regions indicate a broader rejection.
Before allowing a region, consider whether real customers there should also be able to reach the service. A regional denial can be a genuine availability issue rather than a false positive.
Do not hide the problem with accepted codes
Adding 403 or 429 to Accepted HTTP status codes makes that response count as Up and removes its failure diagnosis from future checks. This can be valid for a specialized endpoint whose documented healthy response is that exact code, but it is not a general fix for blocked monitoring.
Prefer correcting the access rule or monitoring a purpose-built endpoint.
When to contact Support
Contact Support if your security configuration should allow the request but monitoring is still rejected or delayed.
Include the monitor name, URL, timestamps, affected regions, displayed diagnosis, and security provider. Include only sanitized rule names and header names. Never send passwords, header values, cookies, private keys, verification codes, or full firewall credentials.