Same here, lots of outbound requests failing and a redeploy resolved it.

Hi Matan — thanks for the detailed report; the deployment/replica IDs and timeline really helped. You diagnosed this correctly: it was a host-level outbound networking failure on the node your replica was running on, not anything in your n8n config. DNS and inbound stayed up while outbound TCP (HTTPS to api.n8n.io / your external Postgres on 5432) was dropped at the host's egress path, which is why the same Postgres was reachable from your laptop. Redeploying moved your service onto a healthy host, which is why connectivity came back immediately — and it's been healthy since that redeploy. This is a known issue we're tracking where a subset of hosts intermittently lose outbound connectivity, and your report is linked to that investigation. For now the practical mitigations are a redeploy (as you found) and a lightweight outbound health check that alerts you early. (Jack — your "same here" is noted and counts toward the same investigation; a redeploy is the immediate workaround for you too.)

how do you suggest to monitor it? what is this outbound health check you recommended? i cannot afford losing outbound connection for more than few min. i run n8n on railway and if outbound connectivity is lost, how can a monitoring workflow or a watchdog alert me when it's lost ?

For a watchdog you want something that tests outbound connectivity the same way your workflows do, then alerts you the moment it fails. A schedule-triggered n8n workflow is the simplest fit: every minute, have it make an outbound HTTPS request to a couple of stable external endpoints (and a TCP connect to your external Postgres on 5432), and on any timeout or error push an alert to a channel that does not depend on this same service, like a Telegram bot, Slack/Discord webhook, or an email API. Because the alert path is external, it still fires even when this service's egress is down.

Pair that with a third-party uptime monitor (UptimeRobot, Healthchecks.io, Better Stack) using their dead-man's-switch mode: your workflow pings their URL on every successful run, and they alert you if the ping stops arriving. That covers the case where the workflow itself can't reach anything outbound. With a 1-minute cadence you would be notified within a couple of minutes of an outbound drop, and a redeploy remains the immediate recovery step.

The underlying host-level egress issue you hit is still linked to our open investigation. Let us know if you would like more detail on setting up either piece.