checked the status page, only live incident is the github one (auto-deploys / PR envs delayed or failing). that hits deploys, not traffic to a running service, so it shouldn't slow your API. compute and public networking are 100% across all regions today: https://status.railway.com/

so probably something on your side. quickest checks:

metrics tab over the window it got slow, if cpu is pinned or memory's near the limit you're resource bound.

if resources look fine, suspect the database. slow queries as data grows is the usual cause of "suddenly slow with no deploy", normally a query missing an index that was fine at lower row counts.

also check your service and db are in the same region, cross-region hops add latency to every query.

if metrics are flat and even a simple health check is slow, then it's worth taking back to staff with a timestamp.

Hello

1. In the metrics tab, all metrics show extremely low usage. Nothing is anywhere near the usage limit.
2. The database, which is connected via DBeaver, responds extremely quickly—0.02 ms at most.
3. All services are in the same region (Virginia).
4. I even checked the type of connection between the backend service and the database, and they’re using Railway’s internal addresses via ${{..}} references.

Below is an image of a health-check route. It’s just a simple route that returns a 200/503 status; there’s no data retrieval or logic involved. The response time for this status check is 1.6–2.4 seconds, much too slow!

that health check is the useful clue. a route with no queries and no logic shouldn't take 1.6s, so the time is going somewhere before your controller runs, not in railway's network.

first thing to do is split app time from network time. open the service's Console tab and curl the health check from inside the container:

time curl -s -o /dev/null -w "%{time_total}\n" http://localhost:$PORT/api/health

if that's also ~2s, it's your app and railway isn't involved at all. if it's fast, the time is being added between the edge and your container.

assuming it's slow internally, the usual laravel causes are bootstrap-level, things that run on every request regardless of route:

session driver. if SESSION_DRIVER is database or redis, every request opens a connection before your route runs, even a health check.

one more worth checking on railway specifically: private networking is ipv6-only. if anything in bootstrap resolves an internal hostname and your php stack tries ipv4 first, you wait for that to fail before it falls back. that produces a consistent 1-2s on every request and would explain why DBeaver looks fast, it connects over the public proxy on ipv4 instead.

quick way to test that one: set SESSION_DRIVER=array temporarily and hit the health check again. if it drops to milliseconds, it's the connection at boot, not railway.