401 vs 403 - What's the Difference and Why It Matters for Monitoring

Two Error Codes, Two Very Different Problems

You set up a monitor on an API endpoint. It returns a 401. Is your service down? You check another endpoint - it returns a 403. Is that also down?

The answer to both is "it depends," and the difference matters more than most teams realize. 401 Unauthorized and 403 Forbidden are often confused because they both result in denied access. But they signal completely different problems, require different fixes, and should trigger different responses in your monitoring.

401 Unauthorized - "Who Are You?"

A 401 response means the server doesn't know who's making the request. The client either didn't provide credentials at all, or the credentials provided are invalid, expired, or malformed.

Despite the name "Unauthorized," this status code is really about authentication - proving your identity - not authorization.

Common causes:

• Missing authentication header - The request didn't include a token, API key, or session cookie
• Expired token - The JWT or OAuth token has passed its expiration time
• Invalid credentials - Wrong API key, revoked token, or incorrect username/password
• Malformed auth header - The Authorization header exists but isn't formatted correctly (e.g., missing the Bearer prefix)

What a 401 tells you:

The server is working fine. It received your request, understood it, and is asking you to authenticate. The service itself isn't broken - the request is.

401 in Monitoring

If your uptime monitor is hitting an authenticated endpoint and suddenly starts getting 401s, the most likely causes are:

1. Your monitoring token expired - If you're using a token with an expiration date, it needs to be rotated
2. API key was revoked or rotated - Someone on your team regenerated the key and didn't update the monitor
3. Auth service is down - If your endpoint validates tokens against an auth service, and that service is unreachable, the endpoint might return 401 instead of a more descriptive error

A 401 from a monitored endpoint usually isn't a real outage - it's a configuration issue with your monitor. But a sudden 401 on an endpoint that was previously returning 200 can indicate an auth service failure, which is a real problem.

403 Forbidden - "I Know Who You Are, but No"

A 403 response means the server knows exactly who you are - authentication succeeded - but you don't have permission to access the requested resource. This is about authorization, not authentication.

Sending more credentials won't help. The server has already identified you and decided you're not allowed.

Common causes:

• Insufficient permissions - Your user role doesn't have access to this endpoint or resource
• IP restriction - The request is coming from an IP address that's not on the allowlist
• Geographic restriction - The service blocks requests from certain countries or regions
• Rate limiting - Some APIs return 403 instead of 429 when you've exceeded your quota
• WAF or firewall rule - A web application firewall is blocking the request based on a rule match
• Resource is disabled - The endpoint exists but has been intentionally turned off

What a 403 tells you:

The server is working, authentication succeeded, but the access policy says no. The service is healthy - you're just not allowed to use this particular part of it.

403 in Monitoring

A 403 from a monitored endpoint is often caused by:

1. IP allowlisting - Your monitoring probe's IP isn't on the target's allowlist. Since probes check from multiple global regions, all probe IPs need to be allowed.
2. WAF blocking - A firewall rule is matching something in the monitoring request (user agent, headers, request pattern) and blocking it
3. Geo-blocking - The endpoint blocks requests from the region where your monitoring probe is located
4. Permission changes - Someone changed the API key's permissions or role, and it no longer has access to the monitored endpoint

A 403 from a monitor is almost never a real outage. It's usually a network or permission configuration issue. But like 401s, a sudden 403 on a previously working endpoint can signal a WAF misconfiguration or an unintended permission change that's also affecting real users.

Side-by-Side Comparison

How to Handle These in Your Monitoring

Don't Monitor Authenticated Endpoints Without Auth

If your endpoint requires authentication, your monitor needs to send valid credentials. Otherwise, you'll get a permanent 401 that tells you nothing about your service's health.

Configure your monitor with:

• An API key or bearer token in the request headers
• A reminder to rotate the token before it expires

Monitor a Public Health Endpoint Instead

The cleanest approach is to expose a dedicated /health or /status endpoint that doesn't require authentication. This endpoint should:

• Return 200 when the service is healthy
• Check internal dependencies (database, cache, auth service)
• Not require any credentials to access
• Not be rate-limited or geo-blocked

This avoids the 401/403 problem entirely and gives your monitor a clear, unambiguous signal.

Set Expected Status Codes

If you must monitor an endpoint that returns 401 or 403 under normal conditions (e.g., verifying that authentication is enforced), configure your monitor to treat that status code as "up." Vantaj lets you define which status codes are considered successful, so a 401 on a protected endpoint can be expected behavior rather than a false alarm.

Alert on Status Code Changes

The most useful signal isn't "this endpoint returns 401" - it's "this endpoint started returning 401 when it was returning 200 yesterday." Monitor for changes in response codes, not just the codes themselves.

If an endpoint flips from 200 to 401, something changed - an expired token, a revoked key, or an auth service failure. If it flips from 200 to 403, something in the access policy changed - a new WAF rule, an IP block, or a permission change.

Quick Reference

Getting a 401?

1. Check if your monitor is sending credentials
2. Verify the token/key hasn't expired or been revoked
3. Confirm the Authorization header format is correct
4. Check if the auth service itself is healthy

Getting a 403?

1. Check if the monitoring probe's IP is allowlisted
2. Review WAF/firewall rules for blocks on the monitor's user agent or request pattern
3. Verify the API key's permissions haven't changed
4. Check for geo-blocking on the probe's region

Best practice? Monitor a public /health endpoint that doesn't require auth. Save yourself the headache.