Error guide

403 Forbidden

The server understood the request and refuses to fulfil it — authentication will not change the answer.

A 403 Forbidden is a refusal. The server understood the request, has whatever identity it needs, and is declining regardless. Unlike a 401, it is not an invitation to try again with credentials — the same request from the same client will be refused every time.

It comes from three quite different places and they need separating early. Your application returns 403 when a user lacks permission for a resource. The web server returns 403 for filesystem and configuration reasons — unreadable files, a directory with no index, an explicit deny rule. And an edge layer, WAF or bot filter returns 403 when it decides a request is hostile, which is by far the most common reason an automated client sees one.

That third source is the one that catches monitoring. A check that works perfectly from a laptop and returns 403 from a monitoring service is nearly always being filtered on its user-agent, its IP range, or the absence of browser-like headers.

Common causes

  • A WAF, bot-protection service or CDN security rule classifying the client as automated.
  • IP allowlisting or geographic blocking that excludes the client's address.
  • The authenticated user genuinely lacking permission for the resource.
  • Filesystem permissions on the server preventing the web server from reading the file.
  • Directory listing disabled with no index file present.
  • A signed URL whose signature has expired or whose parameters were altered.

How to diagnose it

  1. Identify which layer generated it: an edge or WAF 403 usually has a distinctive branded body and a reference ID, and never reaches your application log.
  2. Retry with a normal browser user-agent. If it succeeds, the cause is bot filtering rather than permissions.
  3. Check the WAF or CDN event log for the blocked request and the rule that matched it.
  4. For a file-serving 403, check the filesystem permissions and the ownership of the path the server is resolving to.
  5. For an application 403, log the identity and the permission check that failed — the answer is rarely visible from outside.

Whose fault is it? It depends which layer

It depends on the layer. A permissions 403 is working correctly and the request was wrong. A WAF 403 against legitimate traffic is a server-side configuration problem, and it is the version most likely to be blocking your own monitoring.

What monitoring sees

This is the code most likely to make a monitor lie in the reassuring direction: if a security layer serves the monitor a cheap 403 while real users are served a broken application, criteria that only check for a 200 will report the outage as a normal failure and criteria that treat 403 as acceptable will report it as healthy. If a monitor is blocked, allowlist it at the edge rather than relaxing its criteria.

Related error guides

Terms used on this page

Questions

Why does my uptime monitor get 403 when my browser does not?

A bot filter or WAF is almost certainly the cause. Monitoring requests come from datacentre IP ranges with a non-browser user-agent, which is exactly the pattern these products block. Allowlist the monitor at the edge rather than making the check accept a 403.

Can a 403 be fixed by logging in?

No — that is what makes it a 403 rather than a 401. The server has already decided, and a different identity with more permission would be needed to change the answer, not the same identity authenticating again.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.