499 is an nginx-specific code that appears in access logs when the client closed the connection while nginx was still processing the request. No response is sent, because nobody is left to receive it.
It usually means that the upstream application was slow: the user navigated away, a load balancer or API client hit its own timeout, or a health check gave up. A spike of 499s with long request times points to a slow backend, while a few 499s from users who cancel page loads are normal.
When a proxy in front of nginx times out first, nginx logs 499 while the proxy reports its own error, such as 504 or Cloudflare's 524.
Example response
# The client gave up before nginx had a response; nothing is sent.
# nginx access.log (last field: $request_time in seconds)
198.51.100.23 - - [06/Nov/2026:10:15:32 +0000] "GET /report?year=2026 HTTP/1.1" 499 0 "-" "Mozilla/5.0" 30.001SEO and redirect checking
Crawlers never receive a 499, but if Googlebot gives up waiting for a slow page, your logs show 499 for its requests. That is a sign of slow server response times, which reduce how much Google crawls. Redirect checkers also time out on very slow hops; the Redirect Latency Checker shows which hop is slow.
Common causes and use cases
- The application backend takes longer than the client, CDN or load balancer is willing to wait.
- Users cancel or leave a slow page before it loads.
- Monitoring and health checks use short timeouts.