When a customer reports a problem accessing your web app:
- What are they seeing? Get screenshot or exact error. The status code tells you a lot.
- Where in the path does it break?
- Client side (browser) → check browser console, network tab
- DNS → does
dig example.comresolve? From their location specifically? - CDN / edge (Cloudflare) → CDN dashboard or status page; check cache headers
- Load balancer → LB access logs, target group health, response codes by target
- Application server → app logs, response time, errors
- Database / downstream services → query latency, connection pool, downstream error rates
- Compare with current global health — is this customer-specific, region-specific, or universal?
- Recent changes — anything deployed in the last 24 hours? Any infra changes?
Crisp answer (this is the answer you should have given Ben):
"I'd start with what the customer is seeing — a 500 means server-side, a 502 means upstream issue, a 404 means routing problem. Then trace the path. If it's a 502 from the load balancer, I'd check the load balancer's target health and upstream response codes — likely the application servers are returning errors or are unhealthy. If targets look healthy, I'd check the application logs for the specific error pattern. If the LB itself is fine and targets are healthy, I'd look at downstream dependencies — database, cache, third-party APIs. Across all of this I'd compare against current global metrics: is this one customer, one region, or everyone."