The response time chart shows your p50 (median) stays near 0ms while only the p95/p99 spike, which indicates the slowness affects a small percentage of requests. You can determine whether the latency is in your application or in the network by comparing the totalDuration and upstreamRqDuration fields in your HTTP logs in the Log Explorer. Filter with @requestId: using the request IDs you provided - if upstreamRqDuration is high, the delay is in your application's processing; if totalDuration is high but upstreamRqDuration is low, the latency is in the network path.

I've checked upstreamRqDuration, and the values are consistently high. How can I determine whether the issue is with my Next.js service itself or with Railway's reverse proxy?

I accidentally clicked Resolve by mistake

See the response from the bot:

if upstreamRqDuration is high, the delay is in your application's processing; if totalDuration is high but upstreamRqDuration is low, the latency is in the network path.

So, it's coming from your application.

I randomly checked a few more requests and found that totalDuration and upstreamRqDuration are exactly the same, both in the range of a few hundred milliseconds; with edgeRegion shown as europe-west4-drams3a and my container deployed in us-east, does that really mean the network latency was effectively zero and all of that time was spent in my service?

That's correct. When totalDuration and upstreamRqDuration match, the entire duration was spent in your application processing the request, and the proxy/network overhead was effectively zero.

I’m not very familiar with Next.js, and I also checked another one of my Golang services. It has a health check endpoint with no database calls or any other operations that could introduce latency — it simply returns success — but the latency is still quite high and unstable, ranging from 1 ms to several hundred milliseconds. I noticed that the low-latency records are all from us-east4-eqdc4a, while the high-latency ones are from asia-southeast1-eqsg3a or europe-west4-drams3a. It seems to be strongly related to the edgeRegion, which makes me think it may include network latency.

I’d like to confirm how upstreamRqDuration is calculated. Does it start from the moment the request reaches my container, or does it also include the network latency from the edgeRegion to my container?