2 hours ago
Hi team,
Starting yesterday around 16:09 UTC, several of my background services that connect to an external AWS-hosted API began failing with persistent 504 Gateway Timeout errors.
The target endpoint is Chile's public procurement platform (Mercado Público):
https://api2.mercadopublico.cl/v2/compra-agil/
Prior to that timestamp, these services were functioning normally and running reliably.
I have attached the deployment log showing normal execution followed by the sudden timeouts starting at 16:09 UTC.
While a 504 typically points to an upstream or gateway issue on the destination host, I wanted to verify whether there were any outbound routing, proxy, or egress network changes on Railway's side around that time—especially considering the recent incident banner regarding external network blocks.
Could you please check if outbound traffic from Railway to api2.mercadopublico.cl is encountering any egress routing or proxy blocks?
Best regards,
Attachments
1 Replies
2 hours ago
Your logs show each failing request receiving an HTTP 504 Gateway Timeout response about 29 to 30 seconds after it was sent, which means the connection to the destination was established and a server on their side answered with that status. An outbound block or routing problem on our network would show up as connection failures or connect timeouts, not as an HTTP status code coming back from the remote host.
The same logs show a 429 rate-limit response from that API at 16:09 UTC, shortly before the 504s began at 16:16 UTC, so the destination's own rate limits or gateway timeouts are the place to look. The current external network blocks incident involves some networks refusing traffic from our IP addresses, which produces failed connections rather than a 504 response, so it does not match what your logs show.
Status changed to Awaiting User Response Railway • about 2 hours ago