IL-0345 Render · 2020-12-06networking
Many Render services in the Oregon region returned 503 errors for about four hours
Render's load balancing algorithm for HTTP requests is meant to handle a service that holds requests by rejecting traffic to that service, so that it cannot exhaust TCP connections on a load balancer shared with other services. When a customer API with one of the highest request rates in Oregon started holding requests until they timed out, it exposed a bug in that algorithm, and the load balancers also rejected some requests to other services with 503. Render mitigated the impact until the root cause was found, then rolled out a fix to all of its load balancers.
- Severity
- –
- Scope
- many Render services in the Oregon region and the Render Dashboard
- Users affected
- –
- Region
- Oregon
- Time to detect
- –
- Time to resolve
- 3h 59m
Symptoms
Between 13:34 and 17:33 PST on Sunday 6 December 2020, many Render services in the Oregon region returned 503 (Service Unavailable) errors at an elevated rate, and the Render Dashboard was affected. Render's monitoring alerted the team at once. The status page reported upstream load balancers having trouble connecting to the rest of the infrastructure, and after an apparent fix the connectivity error rates rose again before the final fix.
Symptom High error rate
Root cause
Root cause Software defect
- Trigger
- At 13:34 PST a customer API hosted in Oregon, one of the services with the highest request rates in the region, began holding incoming requests until they timed out.
Detection
Render's monitoring system notified the team immediately.
Remediation
- Rolled out a fix to the load balancing algorithm across all load balancers
Action items
- Add mechanisms that isolate services from each other in the routing and load balancing layers
- Increase test coverage of the load balancing code
- Add synthetic failure states to the continuous integration test suites
- Put more focus on chaos engineering
Lessons
–
Sources
- https://status.render.com/incidents/rn1m41h82n5g · official-status · archived copy
Related cases
IL-0150A latent race condition in DynamoDB's DNS automation left an empty DNS record for dynamodb.us-east-1.amazonaws.com, and the DynamoDB and EC2 launch failures that followed caused EKS, ECS and Fargate container launch failures and cluster scaling delays in us-east-1Amazon Web Services · 2025same root cause · shared Cloud load balancer
IL-0352Heroku Router 2.0 spread HTTP requests unevenly across dynos for four days, causing latency and timeoutsHeroku · 2025same root cause · shared Cloud load balancer
IL-0131A new kind of GenerateContent request made Vertex AI prediction API servers segfault, and once enough of them restarted at the same time the serving fleet could not carry the loadGoogle Cloud · 2024same root cause · shared Cloud load balancer
IL-0529New Google Cloud VMs and other instances came up without network connectivity in all zones after VPC controllers stoppedGoogle Cloud · 2024same root cause · shared Cloud load balancer
IL-0253Firefox froze and could not load any web content for close to two hours, stuck in an HTTP/3 request to TelemetryMozilla · 2022same root cause · shared Cloud load balancer
IL-0243Google's global External Proxy Load Balancing returned 404 errors for most HTTP/S endpoints for 33 minutesGoogle Cloud · 2021same root cause · shared Cloud load balancer
IL-0106A malformed Traefik IngressRoute triggered a Traefik v2 bug once a node rollover restarted every Traefik pod, and all Kubernetes services returned 404DFDS · 2021same root cause · shared Cloud load balancer
IL-0493Netlify's Google Cloud TCP load balancer stopped serving about 5% of global traffic as all backends failed health checksNetlify · 2021same root cause · shared Cloud load balancer
IL-0030Most nodes of a cluster went NotReady together for 15 minutes while the API server sat behind an AWS ELBZalando · 2019same root cause · shared Cloud load balancer
IL-0338Google Cloud HTTP(S) and TCP/SSL Proxy load balancers returned 502s or reset connections on 33% to 87% of requestsGoogle Cloud · 2018same root cause · shared Cloud load balancer
IL-0395Google Cloud HTTP(S) Load Balancer gave 502s on 25% of requests for 22 minutes after reverting to a stale configurationGoogle Cloud · 2017same root cause · shared Cloud load balancer
IL-0396New or live-migrated GCE instances, VPN tunnels and network load balancers were unreachable on public IPs for over 2hGoogle Cloud · 2017same root cause · shared Cloud load balancer
Check your cluster for this
For AI tools and scripts
- This case as JSON: https://incidentlib-api.benchlet.com/cases/IL-0345
- The cases most like it: https://incidentlib-api.benchlet.com/cases/IL-0345/similar
- MCP server (Streamable HTTP, no key):
https://incidentlib-mcp.benchlet.com/mcp
The API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.