Hi — good news first: your Postgres instance is healthy and online. On our side I can see it actively serving connections over your project's private network right now (steady traffic, no drops), so there's no data loss or database outage here.

The problem is isolated to the public TCP proxy mapping for the service — external connections aren't being forwarded to the container at all, even though the database itself is fine. Your diagnostics line up exactly: the proxy frontend answers on :443, but the assigned port times out, and the dropped ICMP is normal for our infrastructure (not a signal). We most often see this when a service's proxy registration goes stale after a host event. I also checked our status — there's no active platform incident overlapping when this started, so this is specific to your service's proxy registration rather than a regional outage.

Please try this first: redeploy the Postgres service — open the service → Deployments → ⋮ on the latest deployment → Redeploy. That re-registers the TCP proxy and usually restores external connectivity within a minute. Your endpoint shouldn't change; you can confirm the current domain/port under Settings → Networking → TCP Proxy.

If it's still timing out after the redeploy, reply here and we'll investigate the host directly.

One note for resilience: since your app and database are in the same project, your services should connect over the private *.railway.internal URL for production — that path has stayed fully healthy throughout, so it keeps you off the public proxy entirely.