Could definitely be the connections. When you run into these, can you try to run SELECT * FROM pg_stat_activity; on Postgres and see how many connections you have open?

Lambdas pretty wirey in the sense that it'll just create a new connection for every request so you may end up flooding the DB. We do connection pooling at the edge, but if you're opening a lot of connections here we might rate limit you on connection opens

I'll circle back with what our rate limits are on connections in the next hour

Thanks for the answer jake. Usually it's around thirty by the time I get to running that query, so I'm not sure that that's the reason, although rate limit makes sense since we'd be opening and closing a lot of connections in a very small timeframe (thousands of connections per minute possibly).

Need a way to bypass any rate limiting if that's the case.

I'm being informed there's no rate limit for TCP connections

Can we get a timestamp for when this occured?

Here's a few timestamps.

This is a very small sample out of 2000+ events.

Updating you on the progress from our side- nothing conclusive but we are having eng. look into this. In the meantime, have you observed any more behavior like this as of late?

No, the most recent instance was 4 days ago. But the system that we use here has barely been used in that time period so it’s hard to tell.

I will mark this as resolved but do you have access to our Slack. Feel free to ping us immediately so we can address it.

No, I don't have access to the Slack. How do I get access here? This issue is ongoing by the way.

We invited you to join a Railway Slack channel on November 12. I've resent the invite emails from Slack.

We've identified a possible issue causing the timeouts and deployed a fix for it. Please let us know if it happens again.

In the meantime, I'm this thread in favor of the conversation in Slack.