I’d recommend investigating the amount of API calls people are making. Under normal circumstances, it’s very hard to reach Railway’s rate limits.

After 5 hours, the rate limit stopped and everything went back to normal

It happened again. I think I found the cause. Both times I got rate limitted where right after sending this message to the Railway Agent in one of my projects: "Deploy the latest commits on all apps". I have 22 apps in this environment of my project and after sending this message, I got rate limitted for all users in my wifi. After connecting to my iPhone internet, the Agents tab is buggy and it's very hard to open this thread. I think there is a bug with the Railway Agent.

However, the agent responded correctly and the apps got deployed as expected.

Your repro is a good one, and it explains the "whole office at once" part, which is the odd bit.

Why everyone on the office wifi got hit. Railway's documented API limits are per token (Hobby 1,000 req/h and 10 req/s; Pro 10,000 req/h and 50 req/s, with X-RateLimit-Remaining / Retry-After headers on the responses). A per-token limit can't block your colleagues, though — they have their own tokens. What you observed (everyone behind the same office IP blocked, phone tether immediately fine) is the signature of an additional per-source-IP protection at the edge, in front of the dashboard and CLI. Your office NAT makes 10 people look like one client, so one user's burst spends the budget for all of them. That layer isn't in the docs, which is why it's worth flagging to Railway with your exact timestamps and the X-Railway-Request-Id of a blocked request so they can confirm and tune it.

Why "deploy all 22 apps" triggers it. It's less the agent's own work (that runs server-side) and more what the dashboard does right after: 22 deployments start at once and the open tab subscribes to build logs, deploy status and metrics for each of them, i.e. dozens of requests/streams per second from one browser — well above the 10–50 req/s the documented limits allow per client, and apparently enough to trip the IP-level one too.

Practical workarounds until they adjust it:

Do bulk deploys from the CLI or API with a token, not from the dashboard session: a loop of railway redeploy --service --yes (or railway up) from a CI job spreads the calls out, stays under the per-token budget, and doesn't open 22 live log streams in a browser from the office IP.

If you do use the agent for a fan-out, close the project canvas/logs tabs right after you send the prompt — the polling is what's expensive, not the prompt.

When it happens, check the response headers in the browser's network tab: Retry-After tells you how long the block lasts, and X-RateLimit-* tells you whether it's the per-token limit or something else (no headers + 429 for everyone = the IP layer).

Please do report it as an agent/dashboard issue with the numbers above — 22 services is not an unreasonable environment, and a single "deploy everything" locking out an office is a bug from the user's side of things.