The ETIMEDOUT errors and temporary outages you're experiencing during Redis deployments are likely related to how the service transition occurs between the old and new deployments. When a new deployment occurs, the previous version is usually stopped and removed, which can lead to some downtime if the transition isn't handled smoothly.

To address this, you might want to explore the deployment lifecycle settings available in Railway.

Specifically, you can configure an overlap time where the old deployment is kept active for a short period after the new one is live. This can help ensure zero downtime by allowing connections to gracefully transition to the new deployment without interruption. You can adjust these settings in the service configuration section of your Railway project.

Additionally, ensure that your Express server and Socket.io are configured to handle potential reconnections gracefully. Since Socket.io is used for real-time communications, any momentary disconnection might cause these timeout errors. You might also want to verify that your environment is set up to use the private network for internal communication, as this can reduce latency and connection issues during such transitions.

For more detailed guidance, you can refer to Railway's documentation on deployment teardown, which covers these configuration options. If you're using the private network, ensure your configurations align with the private networking guide.

Thanks for your help on this

You might also want to verify that your environment is set up to use the private network for internal communication

• Our web app uses the host redis.railway.internal to connect to Redis – is this what you mean?

In the teardown deployment docs, could I ask what meant by this line "Once the new deployment is active, the previous deployment remains active for a configurable amount of time." in combination with what you've written above "Specifically, you can configure an overlap time where the old deployment is kept active for a short period after the new one is live." Specifically:

• During the overlap window, which deployment is actually the one accepting the requests behind redis.railway.internal – the new or the old deployment?

• It's hard to tell from the Railway docs as a deployment being Active appears to be equivalent to being live / receiving the traffic.

Noted!

1. Yes.
2. Active means that it's alive but not accepting new connections.
3. Noted, I have forwarded this feedback to the engineer

Regardless, let me know if it helps.