a month ago
Hi Railway team,
We checked the backend metrics.
Backend CPU looks very low and memory is stable, so this does not look like CPU/memory saturation.
However, the Response Time chart shows large spikes:
- p95/p99 sometimes reaches around 10–25 seconds
- request error rate is almost flat except one spike
- CPU stays low during the slow periods
This looks more like I/O wait, internal network latency, database connectivity latency, or edge/service routing latency rather than CPU pressure.
We also measured:
GET /health total: ~0.82s
GET /health/db: dbMs around 440ms
All services are in US:
- Backend: US
- PostgreSQL: US
- Redis: US
Plan: Pro
Frontend: cPanel
Backend: Railway
Could you please check if our Railway Postgres and backend are in the same physical zone/region, and whether there are any internal network/database latency issues after the recent US incident?
We can provide screenshots of the Response Time chart showing p95/p99 spikes.
2 Replies
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
After restarting the backend, /health/db improved but is still variable:
Run 1: dbMs 298ms, edge zrh1
Run 2: dbMs 446ms, edge ams1
Run 3: dbMs 149ms, edge zrh1
CPU is low and memory is stable, but Response Time p95/p99 has spikes around 10–25s.
This looks like variable DB/internal network latency or I/O wait rather than CPU saturation.
a month ago
Your Backend and your PostgreSQL database are actually in different regions. You need to replace the public connection string in backend service variables with DATABASE_URL=${{Postgres.INTERNAL_URL}} (or ${{POSTGRES_URL}} which keeps all traffic inside railway local private nertwork.
Also make sure that both your db & backend services are deployed in the exact same region