a month ago
Hi Railway team, I’m trying to debug intermittent high latency on a mostly simple WordPress site and would appreciate help understanding whether Railway sees anything unusual in the request path.
Architecture:
Cloudflare -> Railway public domain -> Caddy reverse proxy service -> WordPress service -> MariaDB
The public domain is personalizedgiftnewspaper.online. Caddy proxies to WordPress over Railway private networking. WordPress and MariaDB are in the same Railway region: europe-west4-drams3a.
The issue:
The site runs well locally, but deployed requests randomly slow down. It is especially noticeable when logged into WordPress admin, where I’m seeing 5s+ page/admin waits. This is not only static/front-end page load work; Railway HTTP logs show slow upstream durations on WordPress admin AJAX and normal GET requests.
I disabled caching/observability plugins to remove noise:
- W3 Total Cache disabled
- DecaLog disabled
- Query Monitor disabled
- W3TC drop-ins removed: advanced-cache.php, db.php, object-cache.php
- Cloudflare cache off for the tested dynamic routes
Resource usage does not look saturated:
- WordPress service max CPU around 0.55 vCPU / 24 vCPU
- WordPress memory max around 1GB / 24GB
- MariaDB max CPU around 0.048 vCPU / 8 vCPU
- MariaDB memory around 304MB / 8GB
- DB connect + SELECT 1 from WordPress is around 19-21ms
Clean no-cache baseline after disabling plugins:
- GET /healthcheck.html: client 77-141ms, Railway upstream 3-58ms
- GET /: client 996-1120ms, Railway upstream 863-902ms
- GET /wp-login.php: client 479-584ms, Railway upstream 393-414ms
- From inside Caddy container to WordPress through the local reverse proxy path:
- /healthcheck.html: ~1ms
- /: ~835-872ms
- /wp-login.php: ~377-393ms
The important bit: for the slow requests, Railway’s totalDuration and upstreamRqDuration are basically identical, so the delay appears to be while Railway is waiting for the service chain to respond, not browser rendering or response transfer.
Examples of AJAX slowdowns:
2026-06-10T10:51:25Z POST /wp-admin/admin-ajax.php 200
totalDuration=6166ms upstreamRqDuration=6166ms requestId=SrW7DELoRBeLCxTN55So4g
2026-06-10T10:51:26Z POST /wp-admin/admin-ajax.php 200
totalDuration=6396ms upstreamRqDuration=6396ms requestId=Y1K7FFHIQFOXi4zvnbOCzg
Examples of normal request slowdowns:
2026-06-10T10:55:13Z GET / 200
totalDuration=1411ms upstreamRqDuration=1411ms requestId=xOdDdM1ARsqO-DSrWUN5dQ
2026-06-10T10:58:22Z GET / 200
totalDuration=1532ms upstreamRqDuration=1530ms requestId=VhZ594faSICYniLxAQeqjw
Routing context:
- Cloudflare colo from my location: LHR
- /.railway/cdn-trace on my domain: pop=ams1 node=aydy
- railway.com trace from the same client: pop=lhr1 node=4rsz
Could someone from Railway check whether these request IDs show anything platform-side: private network stalls, routing/proxy behavior, container scheduling pauses, or anything odd in europe-west4-drams3a?
I’m also happy to run any specific diagnostic command Railway prefers.
I'm aware things like this are hard to diagnose and it could be something I've just incorrectly set up in my but it's just confusing given how smoothly the site runs locally. I've really tried everything and have been seeing this behaviour for months, just asking before I test if it runs better on another platform and all the infrastructure setup that comes with that.
1 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 27 days ago
a month ago
Thanks for sharing all the details. A couple of things I'd test next:
Bypass Caddy entirely and expose WordPress directly on a temporary Railway domain. If latency remains the same, Caddy can likely be ruled out.
Run repeated requests from inside the Caddy container directly to the WordPress container:
curl -w "\nconnect=%{time_connect} starttransfer=%{time_starttransfer} total=%{time_total}\n" -o /dev/null -s http://wordpress:PORT/
Compare the results during both fast and slow periods.
Temporarily switch to a default WordPress theme (Twenty Twenty-Five) and disable all plugins. This helps rule out theme or plugin-related performance issues.
Check whether the slow admin-ajax.php requests are associated with a specific action. A single plugin or heartbeat action is often responsible for these kinds of delays.
Run:
wp cron event list
and temporarily disable WP-Cron to see if scheduled background tasks are causing latency spikes.
If Railway support can inspect the request IDs, I'd be particularly interested in whether they see:
Container scheduling delays
Private networking latency
Proxy retries
Connection pool exhaustion
Cross-node routing anomalies
The fact that totalDuration and upstreamRqDuration are nearly identical suggests the request is spending most of its time waiting on the upstream service chain rather than at the Railway edge.
Based on the data provided so far, my suspicion would still be WordPress/PHP execution rather than Railway itself, but the tests above should make it much easier to confirm where the latency is actually occurring.