9 days ago
Hi Railway Support Team
I am hosting my Next.js application (lotfipiano.ae) on Railway. Recently, we ran an SEO crawl using Ahrefs Site Audit and encountered severe timeout issues and 5xx errors.
While the Time to First Byte (TTFB) is healthy (around 172 ms), the total loading time spikes to 53,686 ms, which eventually results in an "Operation timeout (CURL code 28)".
It seems the container is severely struggling to handle SSR requests and Next.js image optimization under crawl load, causing the server to hang or drop the connections.
Could you please check our project's logs and metrics? We would appreciate any insights on whether our container is hitting its resource limits (CPU/RAM OOM) during these spikes, or if there is a specific network/configuration bottleneck causing these 53-second execution times.
Best regards
2 Replies
9 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 9 days ago
9 days ago
Sir, Railway’s Metrics can confirm whether CPU/RAM limits are causing the issue, while HTTP metrics can show request latency and 5xx rates.
For Next.js SSR, Railway notes that every request consumes server resources, so heavy SSR/data fetching can cause high latency under crawler load.
I’d first check CPU/memory and the affected routes during an Ahrefs crawl; if resources remain normal, the bottleneck is more likely inside the Next.js SSR/image-processing path.
9 days ago
TTFB staying low while total time hits 53s+ points at CPU saturation, not a network issue — requests are getting stuck behind compute-heavy work, not failing to connect.
Strong suspect: Next.js's built-in image optimizer runs sharp transforms on-demand per unique image, same process as your SSR. A crawler hitting many unique pages fast triggers a burst of concurrent image transforms + SSR renders on one container — CPU pegs, everything queues, you get exactly this pattern.
Check Metrics during the crawl window — if CPU's near 100% while RAM stays flat, that confirms it (rules out OOM too).
Fix: bump CPU/replica count so crawl concurrency spreads out, and/or set images: { unoptimized: true } or move image optimization to an external CDN so it's not competing with SSR for the same CPU. Throttling Ahrefs' crawl concurrency is a quick stopgap while you sort the rest.
