504 gateway time-out: How to Diagnose and Fix Gateway Timeout Errors

At 1Byte, we’ve learned to treat a 504 gateway time-out the way seasoned mechanics treat an engine warning light: it’s rarely the actual failure, but it is an honest signal that something upstream is struggling to keep up. Gateway timeouts show up at the worst possible moment—during a product launch, a checkout rush, or a Monday-morning dashboard refresh—because they’re symptoms of systems operating near their limits, not systems idling comfortably.

Economically, that makes the humble 504 more than a technical nuisance. Cloud adoption has pushed more business-critical traffic through layers of proxies, CDNs, ingress controllers, and service meshes; Gartner forecast worldwide public cloud end-user spending would total $675.4 billion in 2024, which is another way of saying “more gateways exist between customers and your code than ever before.” Operationally, the stakes are equally blunt: Uptime Institute’s annual analysis reports 54% of respondents to the 2023 data center survey say their most recent significant outage cost more than $100,000, and timeouts are one of the easiest outage “shapes” to trigger when dependencies get slow.

In this guide, we’ll diagnose 504s the way we do in our own hosting and cloud operations: by isolating where time is being lost, proving the bottleneck with repeatable tests, and fixing the real constraint instead of simply extending timeouts until the next incident becomes even harder to debug.

Understanding the 504 gateway time-out status code

1. Gateway or proxy did not receive a timely response from the upstream server

A 504 gateway time-out means an intermediary—often a reverse proxy (Nginx), load balancer (ALB), API gateway, or CDN edge—waited for an upstream server to respond and gave up before a response arrived. MDN describes it plainly: the gateway cannot get a response in time while acting as a gateway or proxy.

From our perspective as a hosting provider, the crucial mental model is “who is holding the stopwatch.” The client (browser/app) is not the component emitting the 504; the gateway is. That gateway might be inside your stack (your own Nginx reverse proxy) or outside it (a CDN like CloudFront in front of your origin). Either way, a 504 is the gateway’s opinion that the upstream is too slow or unreachable for too long.

What “Upstream” Usually Means in Real Deployments

In production, “upstream” is rarely a single server. It might be PHP-FPM behind Nginx, a Node.js service behind an ingress controller, a container behind a Kubernetes Service, or an internal API behind a corporate firewall. In multi-tier apps, a slow database call can look like a slow application server, which then looks like a slow upstream to the gateway—so we always follow the chain.

2. How 504 differs from 502 Bad Gateway

We separate 502 and 504 by asking a single question: did the gateway receive a response, and was it meaningful?

• 502 Bad Gateway tends to mean the gateway got something back—an invalid response, a connection reset at the wrong time, a malformed header, or a protocol mismatch (for example, speaking HTTP to an HTTPS upstream).
• 504 Gateway Time-out typically means the gateway didn’t get a usable response within its configured window, even if the upstream might eventually respond if you waited longer.

In practice, we’ve seen 502s cluster around “hard failures” (crashed processes, TLS negotiation issues, upstream refusing connections) while 504s cluster around “slow failures” (lock contention, saturated CPU, overloaded thread pools, database queries that scan too much, or dependency calls waiting on another dependency). That’s not a rule, but it’s a reliable first approximation when you’re triaging under pressure.

3. When the issue is server side vs client networking configuration problems

Because 504s are emitted by gateways, we default to server-side investigation. Still, client networking can be the spark that lights the fuse. A corporate proxy that intermittently drops long-lived connections, a VPN with unstable routes, or a DNS resolver that returns an internal IP for an external hostname can create an “only me” experience even when the upstream is fine.

We draw the boundary this way: if multiple independent clients in different networks see the 504 at roughly the same time, the problem is almost certainly in the server path (edge, gateway, origin, or dependency). If the issue is isolated to one site, one office, or one device type, client networking and local DNS become credible suspects. The trick is not to “pick a side” too early; instead, we prove the scope first, then zoom in.

Initial triage for a 504 gateway time-out error

1. Refresh and retry to recover from transient overload or temporary outages

When we see a fresh 504 report, we start with the unglamorous step: retry. Transient overload is real—autoscaling takes time, cold starts happen, and a brief dependency stall can trigger a timeout wave that clears a minute later.

During triage, we prefer controlled retries instead of frantic clicking. A single refresh might succeed because the upstream cache warmed, a stuck lock cleared, or a new instance joined the pool. On the other hand, rapid-fire refreshes can amplify the problem by turning a slow upstream into a thundering herd. If you control the client, implement exponential backoff with jitter; if you don’t, at least avoid instructing users to “keep trying” without guidance.

Our Rule of Thumb During Incidents

At 1Byte, we treat retries as a diagnostic tool, not a fix. If a retry succeeds, we log that outcome because it suggests contention, queuing, or uneven load distribution rather than a complete outage.

2. Confirm whether the site is down for other people or isolated to one client

Scope is everything. If only one person can’t reach the site, we don’t want to burn an hour tuning Nginx when the real issue is an ISP DNS resolver returning stale records.

To confirm scope, we use at least two independent vantage points: (a) an external synthetic check from a different network, and (b) an internal check that bypasses the CDN when possible. A status page, third-party uptime monitor, or even a quick request from a cloud VM in another region can help establish whether the gateway is failing globally or locally.

3. Reproduce across devices and browsers to compare desktop vs mobile behavior

Comparing device classes isn’t superstition; it reveals path differences. Mobile networks may traverse carrier NAT, different DNS resolvers, and different peering paths. Desktop requests may include larger cookies, heavier headers, or corporate proxy interception.

We reproduce with a short matrix: one desktop browser, one mobile device on Wi‑Fi, and one mobile device on cellular. If only the “big cookie” browser fails, header size limits and upstream buffer settings move up our list. If only cellular fails, CDN edge selection and ISP path instability become more plausible.

4. Set expectations for users when upstream timeouts happen

Timeouts are uniquely frustrating because they feel like silence. Users don’t know whether to wait, retry, or abandon the flow. In our view, incident communication is part of system design: a clear status message reduces repeated retries, lowers support volume, and buys your engineers the quiet they need to fix the real problem.

We recommend a short, human message that admits what’s happening (“requests are timing out”), tells users what to do (“try again in a few minutes”), and sets a channel for updates. If you operate an API, consider returning a structured error body even when the gateway generates the status code, so clients can distinguish “edge timeout” from “application rejection.”

Network and DNS troubleshooting from Layer 1 to Layer 3

1. Layer 1 and Layer 2 checks for link lights cables and correct ports

Yes, it sounds too basic for a cloud-era article, and yes, we still do it. We’ve seen edge servers in a rack with a partially seated cable, a mispatched port, or a switch interface flapping just enough to trigger sporadic gateway errors.

On-prem or hybrid deployments make this especially relevant: a gateway in the cloud might be healthy, while the upstream origin in a private network has an L1/L2 problem. If you have physical gear, confirm link state, duplex negotiation, error counters, and whether the correct VLAN is in play. In virtualized environments, check the hypervisor’s virtual switch, security policies, and any recent changes to NIC offload settings that can create strange packet-loss patterns.

2. Layer 3 reachability tests including ping to 8.8.8.8 and the configured gateway

Once L1/L2 looks sane, we validate Layer 3: can packets reliably reach the next hop and a known-stable external target? The configured gateway is the first checkpoint; if it’s intermittently unreachable, everything above it is going to look haunted.

For a quick external sanity test, we often ping 8.8.8.8 because it helps distinguish “DNS is broken” from “the internet path is broken.” If the gateway is reachable but external targets aren’t, look upstream (ISP, firewall egress rules, or routing). If external targets respond but your origin doesn’t, the problem likely lives in your environment.

A Practical Note About ICMP

Some networks block ICMP, so a failed ping is not definitive. In those cases, we prefer TCP-based probes (for example, attempting a TCP handshake to the service port) because they align better with what HTTP actually needs.

3. DNS resolution checks including nslookup tests and local DNS cache flushing

DNS is where “it works for me” stories are born. A gateway timeout can be triggered by a gateway trying to reach an upstream hostname that resolves to the wrong address, an unreachable private IP, or a dead instance that’s still cached somewhere.

We validate DNS at three layers: the client resolver, the gateway resolver, and the authoritative zone. Running nslookup or dig from the same host that emits the 504 is more valuable than running it from your laptop, because you’re testing the same resolver configuration and cache. If you use short-lived origins (autoscaled instances, containers, blue/green deployments), stale records can become a silent failure mode—especially when combined with long connection reuse at proxies.

4. Firewall proxy and security rules that can block CDN traffic or upstream access

We’ve debugged plenty of 504s that were ultimately “policy timeouts.” A firewall drops idle connections, a proxy requires authentication, a WAF blocks a request body pattern, or a security group only allows traffic from a previous CDN IP range.

Start by mapping the path: viewer → CDN → gateway → origin. Then confirm each hop is permitted in both directions. For CDNs, the origin must accept inbound requests from the CDN’s egress addresses or through an approved private link. For internal upstreams, the gateway must have egress permission and a route to reach them. When rules are too strict, the gateway can hang waiting for a SYN‑ACK that never arrives, and the outcome looks indistinguishable from “the app is slow” until you check the network logs.

Diagnosing upstream delays behind Nginx

1. Check Nginx error logs and upstream server logs for timeouts and connectivity issues

Nginx is usually candid about timeouts—if you’re looking in the right place. Our first stop is the Nginx error.log for messages such as “upstream timed out,” “connect() failed,” or “no live upstreams.” Those lines tell us whether the timeout happened while connecting, while sending the request, or while reading the response.

Next, we correlate with upstream logs: application logs, PHP-FPM slow logs, JVM GC logs, database logs, and load balancer access logs. A 504 without any upstream trace often indicates the request never reached the upstream at all (routing, firewall, DNS, or connection pool exhaustion). Conversely, if the upstream shows the request started but finished late, we focus on what consumed time inside the application: locks, queries, external API calls, or synchronous background work that should have been asynchronous.

Log Correlation We Trust

At 1Byte, we’re fond of end-to-end request IDs. If Nginx injects a request ID header and every upstream service logs it, the “where did time go?” question becomes answerable instead of philosophical.

2. Measure upstream response time with curl timing output

We prefer measurements over hunches, and curl gives fast, repeatable timing breakdowns. A simple approach is to hit the gateway endpoint and record DNS time, connect time, TLS handshake time, time to first byte, and total time.

curl -s -o /dev/null \  -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}" \  https://example.com/health

When total time is high but TTFB is low, we suspect download stalls, large responses, or client-side throttling. When TTFB balloons, the upstream is slow to start responding—classic for expensive queries or a dependency call waiting on another system. If DNS time is the outlier, the fix might be as simple as resolver configuration on the gateway host.

3. Verify Nginx to upstream connectivity using ping traceroute and mtr

Even when the upstream is “healthy,” the path between Nginx and upstream can be the culprit. Routing changes, asymmetric paths, intermittent packet loss, or MTU mismatches can create a world where short requests succeed and long responses fail.

We use traceroute to see where paths diverge and mtr to observe packet loss patterns over time, because a single snapshot can lie. In cloud networks, don’t forget to check security groups, NACLs, and route tables—those are your L3 truth. If you’re traversing the public internet between gateway and origin, expect variance; if you’re traversing a private backbone, variance suggests a misconfiguration or a failing network component.

4. Review Nginx and upstream server configuration for misconfigurations that cause delays

Misconfiguration is a sneaky form of “slowness.” We’ve seen 504s caused by too-small upstream connection pools, disabled keepalives that force repeated TCP/TLS handshakes, and buffering settings that accidentally turn streaming endpoints into memory pressure events.

On the upstream side, application server thread pools and database connection limits matter. An overloaded pool doesn’t always crash; it queues. That queue becomes “time spent before upstream responds,” which becomes a 504 at the gateway. We also look for mismatched expectations: gateways that allow large request bodies while upstreams reject them slowly, or upstreams that stream data while gateways buffer it all before sending anything to the client.

Fixing 504 gateway time-out in Nginx reverse proxy setups

1. Increase proxy_connect_timeout proxy_send_timeout proxy_read_timeout and send_timeout

Timeout tuning is often necessary, but it should be done with discipline. If the upstream legitimately needs more time (for example, a report export endpoint), then increasing the gateway timeouts can be appropriate—provided you also protect the system from abuse and manage concurrency so slow requests don’t starve fast ones.

We tie timeout changes to an identified scenario and document why. Nginx exposes the knobs through directives like proxy_connect_timeout, and we recommend adjusting them alongside upstream capacity planning rather than as a stand-alone “make the error go away” move.

A Safer Pattern Than “Raise the Timeout”

• Make slow endpoints asynchronous when possible.
• Return a job ID immediately, then let clients poll or receive a callback.
• Rate-limit expensive routes so a single user can’t monopolize upstream workers.

2. Optimize upstream performance with scaling resources database query optimization and load balancing

Most persistent 504s we’ve fixed weren’t “proxy problems.” They were upstream performance problems made visible by the proxy. Scaling is the blunt instrument—more CPU, more memory, more instances—and sometimes it’s exactly what’s needed when load is genuinely higher than expected.

Still, we’ve also watched teams scale an inefficient query from “slow” to “expensive and still slow.” Query optimization, indexing, and reducing N+1 patterns often provide more durable wins than brute force. Load balancing helps when a single upstream node is hot, but it won’t help if every node is blocked on the same database lock or the same third-party API. Our habit is to profile first, then scale the constrained tier.

3. Improve network stability by validating firewall rules upgrading network hardware and using reliable providers

Network-induced 504s tend to be intermittent, which makes them tempting to dismiss. Yet intermittent failures are exactly what customers remember: “your site is flaky.”

We validate stability with continuous probes between gateway and origin. If packet loss appears, we investigate physical components (switch ports, NIC errors), virtual components (overlay networks, mis-sized NAT gateways), and policy components (stateful firewalls timing out idle flows). In multi-cloud or hybrid setups, the highest leverage fix is often boring: simplify the path, reduce the number of middleboxes, and ensure the remaining providers are reliable and well-monitored.

4. Implement caching to reduce upstream load and improve response times

Caching is one of the few techniques that simultaneously reduces upstream load and reduces user-perceived latency. At 1Byte, we view caching as a way to “buy back time” that you can spend on correctness and resiliency.

At the gateway, Nginx can cache responses for cacheable routes, which reduces repeat work for identical requests. At the edge, a CDN can absorb traffic spikes that would otherwise hammer origins. Inside the app, object caching and query result caching can turn repeated expensive operations into cheap memory lookups. The deeper lesson is that caching is not a feature you bolt on; it’s a contract you define. Once you decide what can be cached, for how long, and under which keys, timeouts become rarer because the upstream has fewer reasons to work so hard on every request.

CloudFront HTTP 504 gateway time-out troubleshooting

1. CloudFront 504 triggers when the origin returns 504 or does not respond before the request expires

CloudFront sits at the edge, which means it’s often the component returning the 504 your users see. In that scenario, CloudFront might be forwarding a 504 from your origin, or it might be timing out while waiting for your origin to respond.

From an operator’s standpoint, the difference matters. If your origin is generating 504s, the fix likely lives at the origin (application performance, database pressure, upstream dependency health). If CloudFront is timing out while the origin is silent, the fix might be origin reachability (firewalls, security groups, routing) or origin performance (slow responses under load). Either way, we want to prove which side started the failure before changing settings.

2. Ensure origin reachability by validating firewall rules security groups and public internet accessibility

Origin reachability problems masquerade as “slow apps” because the edge waits, then gives up. We start with a simple question: can CloudFront reach the origin at all?

For public origins, confirm the origin is publicly reachable (or reachable via the intended mechanism), that security groups allow inbound from the required sources, and that network ACLs aren’t silently dropping return traffic. For private origins, confirm the private connectivity design matches reality—if you intended traffic to traverse a private path, any accidental public routing can create brittle behavior and surprise timeouts.

3. Test origin connectivity on ports 80 and 443 using nc or telnet

Connectivity tests should mimic the protocol path, not just the IP path. Instead of relying solely on ping, we test whether a TCP connection can be established to the origin service endpoints using tools like nc or telnet.

# Replace $ORIGIN_HOST and $PORT with your origin hostname and the service portnc -vz $ORIGIN_HOST $PORT# If telnet is available, it can also verify the TCP handshaketelnet $ORIGIN_HOST $PORT

If TCP handshakes fail intermittently, focus on security group rules, upstream listener health, and any middleboxes between edge and origin. When TCP succeeds but HTTPS requests fail, certificate chains, SNI, and origin TLS policies move to the top of our list.

4. Measure latency tune application performance and only then adjust CloudFront origin response timeout

We’ll say it the way we say it internally: raise timeouts last. The cleanest CloudFront configuration in the world won’t fix an origin that is consistently slow because it’s CPU-starved, waiting on a locked table, or blocked on a third-party dependency.

After measuring origin performance and addressing bottlenecks, it can be appropriate to adjust CloudFront’s origin response timeout to match legitimate workload characteristics. AWS documents that the origin read timeout has a minimum timeout is 1 second, the maximum is 120 seconds, and the default is 30 seconds, and any change should be justified by real request traces rather than hopeful guesswork.

Application level scenarios that lead to timeouts

1. Long running API requests and large responses that exceed default proxy timeouts

Some 504s are not “bugs,” they’re architectural mismatches. A synchronous HTTP request is a poor container for long-running work, especially when multiple gateways and clients each impose their own timeout expectations.

When APIs time out, we look for endpoints doing heavy work inline: exporting large datasets, generating PDFs, running complex search queries, or performing multi-step transactions that call several dependencies. Our fixes typically involve one of three moves: paginate responses, stream results (carefully, with proper buffering settings), or push the heavy work into background jobs. A job queue plus a status endpoint is often less glamorous than a single “do everything” API call, but it’s far more resilient under real traffic.

2. Azure Logic Apps approaches using async responses polling and webhook or messaging patterns

Integration platforms are frequent timeout generators because they orchestrate multiple systems that each have their own latency quirks. In Azure Logic Apps, we often recommend embracing asynchronous patterns—respond quickly to the caller, then continue work in the background using polling, callbacks, or messaging.

In practice, we’ll implement a “submit → acknowledge → process → notify” flow: the initial request returns immediately with a correlation ID, processing happens via a queue or event, and completion is delivered through a webhook or a downstream message. Microsoft’s guidance on building workflows that expose APIs aligns well with this pattern, and it helps keep gateways from being held hostage by slow third-party responses.

Why Async Beats Long Timeouts

Async design reduces the blast radius. A slow dependency doesn’t consume a gateway worker for the entire duration, and user experience improves because clients can display progress rather than spinning until a timeout hits.

3. WordPress workloads where resource heavy feeds plugins or scripts can exhaust server capacity

WordPress is a common source of “surprise 504s” because a single plugin can turn a lightweight page load into a heavy backend operation. We’ve seen resource-heavy feeds, poorly optimized page builders, expensive search plugins, and aggressive security scans saturate CPU or PHP workers until the gateway starts timing out.

Our approach is to profile before guessing. We look at PHP-FPM process saturation, slow query logs, and plugin-level profiling. When a particular route triggers 504s (admin endpoints, feed generation, product sync jobs), we isolate it, cache what can be cached, and move scheduled work off the request path. If the site has periodic spikes, object caching and a CDN often change the game more than tweaking timeouts.

4. When to upgrade the hosting plan review error logs and contact the hosting provider

Sometimes the fix is simply admitting the workload outgrew the box. If CPU is pegged, memory is swapping, or I/O is saturated, no proxy timeout value will create capacity that doesn’t exist.

We advise upgrading when evidence points to chronic resource pressure: sustained high load, consistent slow backend responses, or frequent worker pool exhaustion during normal business hours. Before upgrading, review error logs and performance metrics so you don’t pay more money to run the same inefficiency faster. If you host with us at 1Byte, we’ll typically ask for a short window of logs, a list of slow endpoints, and any recent deployment changes; from there, we can recommend whether you need more resources, better caching, or a structural change like separating the database tier.

How 1Byte reduces 504 gateway time-out risk as an AWS Partner

1. Domain registration and DNS foundations to support stable routing and origin reachability

We’ve come to believe DNS is “silent uptime.” When it’s correct, nobody notices; when it’s wrong, everything looks broken. As 1Byte, we put emphasis on getting domain registration and DNS fundamentals right because 504s can be downstream symptoms of upstream name resolution problems.

Our stance is pragmatic: keep DNS zones clean, remove stale records aggressively, and design for safe change. That means change control for DNS edits, clear ownership, and a rollback plan. For customers running multi-origin setups (blue/green, failover origins), we also encourage DNS and routing designs that don’t rely on last-minute heroics during an incident.

2. SSL certificates to support secure HTTPS connectivity for sites and applications

TLS problems can look like timeouts when connections stall during negotiation, especially when gateways attempt retries behind the scenes. Certificate expiry, incomplete chains, and misaligned origin TLS policies can all create the “edge waits, origin never completes” feeling that ends in a 504.

From our operations seat, certificate automation is less about convenience and more about risk reduction. Automated issuance and renewal, consistent certificate chain configuration, and periodic validation from multiple networks help keep “surprise TLS failures” from becoming customer-visible gateway errors. When we pair this with good observability—handshake error rates, origin connection errors—we usually spot certificate-related issues before users do.

3. WordPress hosting shared hosting cloud hosting and cloud servers supported by our AWS Partner capabilities

Reducing 504 risk is ultimately about matching workload shape to infrastructure shape. That’s why we offer multiple hosting tiers—from shared hosting for small sites to cloud servers for predictable performance and isolation, and cloud hosting architectures designed for scaling and resilience.

On AWS-backed deployments, we can place the right layers in the right roles: CDN at the edge, load balancing where it belongs, and origins sized to handle real concurrency. The practical benefit is not just “more power,” but better fault isolation: a noisy neighbor in one place doesn’t have to become a gateway timeout everywhere. When customers outgrow a single-instance model, we help them evolve toward architectures where the gateway is no longer the single point of disappointment.

Conclusion: 504 gateway time-out checklist and escalation path

1. Locate the timeout point client network gateway or proxy and upstream origin

A 504 becomes solvable once we locate where time is being consumed. Start by identifying which component is returning the status code (browser dev tools, CDN logs, load balancer logs, Nginx logs). Then map the request path hop by hop until you can say, with confidence, “the delay starts here.”

In our day-to-day at 1Byte, we treat that mapping exercise as the difference between debugging and guessing. Once the timeout point is known, the fix options narrow dramatically—and the time-to-recovery improves just as dramatically.

2. Prioritize root-cause fixes before raising timeouts to avoid masking performance issues

Raising timeouts can be valid, but it’s frequently used as camouflage for upstream slowness. That camouflage has a cost: it increases concurrency pressure, stretches resource usage, and makes incidents last longer because failures take longer to surface.

Our escalation path is to fix root causes first: remove pathological queries, add caching, scale the constrained tier, and harden connectivity. Only after the system is healthy do we tune timeouts to reflect legitimate processing time, and even then we pair it with rate limiting and observability so slow requests can’t quietly consume the entire system.

Discover Our Services​

Leverage 1Byte’s strong cloud computing expertise to boost your business in a big way

Domains

1Byte provides complete domain registration services that include dedicated support staff, educated customer care, reasonable costs, as well as a domain price search tool.

Domain Names

SSL Certificates

Elevate your online security with 1Byte's SSL Service. Unparalleled protection, seamless integration, and peace of mind for your digital journey.

SSL Certificates​

Cloud Server

No matter the cloud server package you pick, you can rely on 1Byte for dependability, privacy, security, and a stress-free experience that is essential for successful businesses.

Cloud Server services

Shared Hosting

Choosing us as your shared hosting provider allows you to get excellent value for your money while enjoying the same level of quality and functionality as more expensive options.

Shared Hosting​

Cloud Hosting

Through highly flexible programs, 1Byte's cutting-edge cloud hosting gives great solutions to small and medium-sized businesses faster, more securely, and at reduced costs.

Cloud Hosting services

WordPress Hosting

Stay ahead of the competition with 1Byte's innovative WordPress hosting services. Our feature-rich plans and unmatched reliability ensure your website stands out and delivers an unforgettable user experience.

WordPress Hosting​

AWS Partner

As an official AWS Partner, one of our primary responsibilities is to assist businesses in modernizing their operations and make the most of their journeys to the cloud with AWS.

AWS services

3. Validate changes with repeatable tests and monitor for recurrence under normal and high load

Every change deserves a verification plan. We validate with repeatable tests: the same curl timing command, the same synthetic probes, and the same log queries before and after the fix. If the issue happened under load, we also reproduce under controlled load rather than trusting a quiet period as “proof.”

Monitoring closes the loop: track upstream latency, error rates, and gateway timeouts together, not in isolation. If you’re dealing with recurring 504s, the next step we’d suggest is simple—pick one endpoint that times out, instrument it end-to-end with a request ID, and prove exactly where the time disappears. What would you measure first: the gateway’s upstream timing, the application’s internal spans, or the database’s slow queries?