2 hours ago
Our production Python Discord bot repeatedly received genuine HTTP 429 access denials on Railway, interrupting temporary voice room creation, statistics commands, and activity logs. Normal operations are currently working after a region move, but the earlier cycle of recovery followed by another long block remains unexplained. We are requesting diagnosis and a durable mitigation, not another blind restart or token replacement.
Confirmed historical evidence:
- 2026-10-25 04:13:29 UTC / 13:13:29 Asia/Seoul: temporary voice channel creation was rejected with: "You are being blocked from accessing our API temporarily due to exceeding global rate limits."
- Passive SDK counters in the previous ten minutes: 7 requests, 6 successes and 1 HTTP 429. The previous 60 seconds contained 1 request. This covers this bot's SDK only, not other processes, historical traffic, or other customers.
- Retry-After: 3230 seconds. X-RateLimit-Scope absent; X-RateLimit-Global not true; Via absent. Other confirmed access denials affected multiple API families. We have not established the precise provider enforcement category or a shared-IP cause.
What we checked and changed:
- The affected services moved from Southeast Asia to us-west2 at about 04:34 UTC, retaining their existing volumes. The management bot honored its persisted wait until about 05:07 UTC before reconnecting.
- Statistics image refresh, personal activity records, and temporary room creation/movement/renaming subsequently worked. No new long access denial has appeared in the sampled US West interval so far; this is not proof of permanent recovery.
- Direct runtime inspection found one management bot process/replica. The intended bots use distinct credentials. One IP-echo sample per service showed different public IPv4 addresses, but this does not prove which source address Discord sees per connection or exclude sharing with other customers.
- We reproduced and fixed a separate status-channel defect: an 8-second caller deadline cancelled an SDK route-limit wait and scheduled another edit. Each status channel now retains one in-flight request until it settles, and repeated callers cannot queue copies. Offline tests using the real SDK's route-429 handling passed. This defect has not been established as the cause of the historical hour-long access blocks at low traffic.
- We honor provider waits across restarts, disable production feature trials, and now log actual SDK HTTP 429 responses with sanitized metadata, including responses the SDK handles internally. Local APIPaused messages mean no new request was sent.
- Static outbound IPs and outbound IPv6 are disabled. No proxy is configured. Earlier replacement of only the affected bot application did not solve the denials. We have not removed cooldowns, rotated IPs to bypass restrictions, or reset data.
Could Railway investigate the selected service's outbound networking around the historical denial, clarify whether unrelated tenants can share the identity seen by Discord, and explain how to identify the actual Discord-bound egress address? Is there a durable supported mitigation on the current plan? We understand that static outbound IPs are not guaranteed dedicated, so we do not assume purchasing that feature fixes this issue.
The affected service is selected in the resource field. This public message omits credentials, full IP addresses, private code, member data, and raw logs. Please preserve the existing volumes and data. This request was prepared with an AI assistant from directly checked logs and runtime observations.
3 Replies
2 hours ago
We looked at the selected service's outbound traffic. Our flow data records connections from the container's private address, not the public address Discord sees, so it cannot confirm which public source address a particular Discord connection used. It also cannot show whether another account shared that address at 04:13 UTC. An IP-echo request made from inside the service is the closest view you have of your public egress address, and as you noted, one sample per service does not prove what every connection used.
On sharing: Static Outbound IPs are only available on the Pro plan, and even those addresses are not guaranteed to be dedicated. They may be shared with other customers, so enabling that feature would not guarantee an address no other account uses. We can't point to a self-serve setting on the Hobby plan that gives your bot its own outbound address.
Nothing we can see establishes what triggered Discord's global-limit block. Only Discord can explain which enforcement category applied to that request.
Status changed to Awaiting User Response Railway • about 2 hours ago
Railway
We looked at the selected service's outbound traffic. Our flow data records connections from the container's private address, not the public address Discord sees, so it cannot confirm which public source address a particular Discord connection used. It also cannot show whether another account shared that address at 04:13 UTC. An IP-echo request made from inside the service is the closest view you have of your public egress address, and as you noted, one sample per service does not prove what every connection used. On sharing: Static Outbound IPs are only available on the Pro plan, and even those addresses are not guaranteed to be dedicated. They may be shared with other customers, so enabling that feature would not guarantee an address no other account uses. We can't point to a self-serve setting on the Hobby plan that gives your bot its own outbound address. Nothing we can see establishes what triggered Discord's global-limit block. Only Discord can explain which enforcement category applied to that request.
2 hours ago
Thank you. The recurring access-block cause remains unresolved. Please keep this case open for a Railway engineer to review the selected service’s historical outbound path. Could a human confirm whether the public source mapping for 2026-10-25 04:13:29 UTC can be recovered, whether any platform-side mitigation is available on the current plan, and what connection identifiers or evidence we should provide to Discord? Our code correction is deployed and current operations work, but a successful interval does not explain the earlier repeated low-volume denials. Please preserve the existing volumes and service data.
Status changed to Awaiting Railway Response Railway • about 2 hours ago
an hour ago
We can't recover which public source address a specific Discord connection used at 04:13:29 UTC on 2026-10-25. The network records we keep for your service show the container's private address, not the public address Discord received. That also means we can't confirm or rule out that another account was using the same address at that moment.
There's no setting on the Hobby plan that gives your service its own outbound address. Static Outbound IPs require the Pro plan, and even those addresses may be shared with other customers.
For Discord, the most useful evidence is what you already logged: the exact UTC timestamps of each denial, the request routes affected, the Retry-After values, and the response headers. Include the public addresses your IP-echo checks returned around those times, and say clearly that they're samples, not a confirmed record of the address each connection used.
Status changed to Awaiting User Response angelo-railway • about 1 hour ago