The dashboard Files pane, Console, railway ssh, and the CLI file and volume commands (including railway volume files download) all use the same SSH/SFTP connection to the running service. Switching to another one of these won't get around a connection failure, and restarting a healthy service isn't a remedy either.

A healthy service and reachable HTTPS dashboard don't tell us where the relay connection is failing. Your report alone doesn't establish that the cause is your network or ours.

To look at the right resource, please share the exact CLI command you ran (with any flags), the name of the service and environment you're trying to reach, and the UTC timestamps of the failed attempts from both the CLI and the dashboard Files pane.

Please have a human review these connection failures for the service already linked to this thread. I am keeping its name and identifiers out of this public reply.

Both Windows CLI 5.68.0 attempts ran the same command, shown here with all selector values and the directory path redacted:

railway service files --project <PROJECT_ID> --environment <ENVIRONMENT_ID> --service <SERVICE_ID> list <BACKUP_DIRECTORY> --json

Both exited with code 1 and “Failed to connect to Railway SFTP at ssh.railway.com”, followed by a connection timeout ending “(os error 10060)”. Neither returned a directory listing or started a download.

Timing on November 12, 2026 (UTC):

• The two CLI failures occurred approximately 17:06–17:12 UTC. These are bounds from surrounding events and our saved receipt, not exact command-generated timestamps.
• The dashboard Files “Connection failed” / “Connection lost” observation was recorded by 17:21:44 UTC; its exact failure timestamp was not captured.

Please advise a supported read-only retrieval method or a provider-side remedy. We are not requesting another restart or an application change.

Thanks for the exact command and timings. The service is currently configured with one running replica, which is what SSH-backed file access needs, so a stopped service doesn't explain these failures.

Every official way to read files from a running service, including the dashboard Files pane, Console, railway ssh, and the CLI service and volume file commands, goes over the same SSH/SFTP connection. Because the CLI timed out reaching that endpoint and the dashboard Files pane also lost its connection, using a different one of these tools won't get around it. We don't have a separate official download path that skips that connection.

From what's in the thread so far, we can't tell whether the timeouts are happening between your network and the relay or on our side. A timeout reported by Windows doesn't settle that either way. So right now we can't name a provider-side fix, and we aren't recommending another restart or any change to your application.

This remains unresolved. Please route this existing backup-download issue to a Railway team member for human review.

We understand you need that existing archive, and we're sorry our earlier replies left the cause open between your network and ours. That wasn't the right framing.

Your workspace is active and the service is online with one running replica, as you've also described. In that situation, timeouts reaching the SSH relay, including the Windows 10060 error and the dashboard Files "Connection failed" / "Connection lost" messages, come from the connection between your computer or network and the relay. Troubleshooting that local environment is outside what Railway support covers, and we don't have a provider-side change to make here.

Every official file path for a running service (the dashboard Files pane and Console, railway ssh, and the CLI service and volume file commands) uses that same connection, so there isn't a separate official download route that avoids it. Volume backups are also restored inside the project rather than offered as a downloadable archive. There's no confirmed fix we'd recommend in the form of a restart or an application change, and we're not asking you to make either.