HTTP Status Codes

Use browser DevTools → Network tab, curl -I from the terminal, or tools like Postman. The status code appears in the response header. In code, check response.status.

Authentication ≠ authorization. You're logged in but lack permission for this resource. Check your role/permissions, API scopes, or whether the resource requires admin access. Also check for CORS preflight issues.

A proxy or load balancer got an invalid response from the upstream server. Common causes: upstream crashed, returned malformed data, or the connection was reset. Check upstream server logs, not the proxy.

The browser sends an OPTIONS preflight request before the actual request. Your server must respond with the right Access-Control-Allow-* headers. Make sure your server handles OPTIONS requests and allows the requesting origin.

The endpoint exists but doesn't support POST. Check the Allow response header for supported methods. Common causes: wrong URL (hitting a GET-only endpoint), missing route definition, or a redirect stripping the method.

Always alert on 5xx errors — they mean your server is broken. Alert on 4xx spikes (not individual 404s). Watch for 429s (rate limiting) and unexpected 3xx chains.

Monitor for redirect chains (301 → 301 → 200) and redirect loops. Individual 301/302 responses are usually fine. Excessive redirects add latency and can break crawlers.

Most SLAs don't count 4xx as downtime since they're client errors. But a spike in 4xx on previously working endpoints often signals a broken deploy that changed API contracts.

For 5xx: aim for < 0.1% of total requests. For 4xx: depends on your API, but < 1-5% is typical. The important thing is tracking rate of change, not the absolute number.

Warden checks your endpoints every 30 seconds and alerts immediately on non-2xx responses. It tracks response codes over time so you can spot trends — like a gradual increase in 429s before a full outage.