You open the website and it loads. The monitor says it is down, and the reason it recorded is HTTP 403. Both are true. The site works for you, and it refuses the monitor.
A 403 is the server saying it understood the request and will not do it. Unlike a 503 or a timeout, it is not a sign that the site is struggling. Something decided that this request should not get through.
Why a monitor gets blocked
A monitor is a robot. It asks for a page on a schedule, from servers that are not in the visitor's country, with no browser behind it. Many protections are designed to stop exactly that kind of traffic:
| What blocks it | How it shows up |
|---|---|
| Bot protection or a managed challenge on a CDN or firewall service (Cloudflare is the common example) | A challenge or "checking your browser" page instead of your page; a 403 answer |
| A rule on country or network | Blocks requests coming from data centres or from certain countries |
| A rate limit | Starts to refuse after a number of requests from one address |
| A security module on the web server or hosting panel | Blocks requests that look automatic, or a missing browser identification |
| An address blocklist, for example one kept by an intrusion-prevention tool | Blocks the monitor's address after it was flagged |
| Authentication | A 401 or 403 on a page that needs a login. The monitor does not sign in |
None of these means your site is broken. They mean the protection is working a little too well for a legitimate monitor.
Confirm the cause
Do not change firewall rules on a guess. Look first.
1. Read what the monitor got
If your monitor shows the response, check the body. A page that talks about a security check, a challenge, or a blocked request points to a firewall. A plain "Forbidden" from the web server points to a server rule. A login page points to authentication.
2. Compare from your own terminal
curl -sS -o /dev/null -D - https://example.com/
If this also returns 403 while your browser works, the block depends on how the request looks, not on where you are. Then send a request that looks like a browser:
curl -sS -o /dev/null -D - -A "Mozilla/5.0" https://example.com/
If the second one passes and the first one does not, a rule is looking at the identification the client sends. Look at the headers in the answer too. A header or cookie that names a CDN or firewall service tells you which layer is answering.
3. Read the firewall's own log
This is the most reliable step. Services of this kind keep a log of blocked and challenged requests, with the rule that fired. Find the time of the monitor's failed checks and see which rule matched. The rule name tells you what to change.
4. Test the other direction
Allow the monitor on a narrow rule (see below), run the check again, and see whether it passes. If it does, the block was on the firewall side. If it still fails, look at the next layer: the server's own rules, then the application.
Fix it without weakening the site
The aim is to let one known visitor through, not to turn protection off.
- Allow the monitor's addresses. Most monitoring services publish the addresses their checks come from. Add them to an allow rule, or tell the firewall to skip the protection that blocks the monitor, for those addresses only. If your service does not publish a list, ask its support. UptimeWire publishes its list and the steps for common services: see How to let UptimeWire checks through your firewall.
- Do not rely on the identification string alone. A rule that allows anything calling itself the monitor can be used by anyone. A rule on the address range is much harder to fake.
- Narrow the scope. Allow the monitor to reach one public address, such as the home page or a health page, not the whole site.
- Use a dedicated health address. A small public page that answers 200 and carries no private data is the simplest thing to allow and the cheapest thing to check.
- Mind rate limits. If you check often from several locations, the combined requests may trip a rate limit. Allow the monitor's addresses there too.
- Write down the change. An allow rule that nobody remembers is hard to audit later.
Warning
Do not switch off bot protection or the firewall for the whole site to make a monitor pass. It is a bigger risk than a monitor that reports 403.
When the 403 is real
Sometimes the monitor is right. A deployment that changed file permissions, a security module that was turned on, or an address that is blocked on purpose all produce a 403 that visitors see too. If your own checks from a terminal and from another network also fail, treat it as a real problem and look at the rules and permissions on the server.
What a monitor can and cannot do here
UptimeWire requests a public address from the outside and reads the answer. A final answer from 200 to 399 counts as working. Anything else counts as a failure, and that includes 401 and 403. A failed check is repeated, and an incident opens after three failed checks in a row. The reason is recorded, so you can see "HTTP 403" and when it started.
It does not sign in, answer a challenge, or work around a firewall. Monitoring a page behind a login needs a different approach, or a public health address that stands in for it.
Checklist
- Does the page open in a browser and in
curl? - What does the response body say: a challenge, a plain Forbidden, or a login?
- Which rule fired, according to the firewall's log?
- Are the monitor's addresses allowed, and only for the address you monitor?
- Did you allow the monitor without switching protection off?
- After the change, does the monitor pass for a full day, including busy hours?