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.

Following up with stronger isolation evidence. I have now reproduced the latency without loading WordPress, PHP plugins, the theme, Caddy, Cloudflare or an HTTP request.

Project: 0a02c1bd-24dc-4646-93a6-5ede5f72bda6

Environment: production, 93be4200-eb88-4814-ac34-40927b224746

Region: europe-west4-drams3a

WordPress service: 8fbe860a-0437-4539-82d9-ae03278be9d2

MariaDB service: 48d1de1e-b7ed-4532-8cc3-47821d546f7d

From inside the WordPress service, I opened one raw mysqli connection to MariaDB’s private .railway.internal address. After the connection was established, I ran ten batches of twenty sequential SELECT 1 calls:

• Connection: 22.93ms
• Minimum query round trip: 5.158ms
• Median: 5.200ms
• p95: 5.381ms
• Maximum: 5.602ms
• Mean: 5.260ms

The identical test against local Docker MariaDB averages 0.053ms.

I also tested Redis from the same WordPress container using one authenticated persistent TCP connection to its private .railway.internal address:

• Median PING: 5.760ms
• Mean: 5.781ms
• Maximum: 5.949ms

Seeing the same 5–6ms floor against both MariaDB and Redis suggests private-network round-trip latency rather than database execution or WordPress.

I have also verified:

• Both services are in the same Railway region.
• MariaDB has skip_name_resolve=ON.
• The timed queries reuse an established connection.
• MariaDB currently uses 1/151 connections; historical maximum is 45.
• No resource saturation.
• No active lock contention.
• 99.9996% InnoDB buffer-pool hit rate.
• DISABLE_WP_CRON=true.

WordPress makes approximately 125 sequential queries on these pages, so a 5.26ms round-trip floor alone accounts for roughly 658ms of request time.

Could Railway please check the placement and private-network route between these deployment instances and confirm whether a stable 5–6ms service-to-service round trip is expected in europe-west4-drams3a? The behaviour closely resembles this other report: https://station.railway.com/questions/my-sql-latency-issues-cdeea77b

If possible, could you also confirm whether the services are on different physical hosts or zones and whether rescheduling either service would be a useful diagnostic?

A single digit is expected, as we cannot guarantee workloads in the same region will all deploy to the same availability zone; your services are spread across our two zones. Unfortunately, I can't offer close colocation, as that is only available to Enterprise users at this time.

Oh okay, that's a bit unfortunate but I guess makes sense. I'll have to accept some latency at present then as wordpress plugins all make a bunch of small calls on page load. I've reduced the number of calls as much as possible so hopefully caching can hide most of the page slowdown, might look for another hosting solution given how many calls wordpress needs to make to MySQL every page load. Thanks anyway.