Redeploying the source image usually fixes this problem, you can do it by clicking on your postgres service, press CTRL+K, then select redeploy source image.

Not helped

Try to hard refresh the page, or access it from an incognito tab, to rule out any caching issues.

Hard refreshing or using incognito tab not hepled. I catched error, it appears on 1-2 seconds

Do you see any errors in the database logs?

2026-09-10T12:55:47.597027841Z [inf] Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/dfb88f37-df7d-41a0-9341-dde34251f32d/vol_5narsjd5js3lmzzc

2026-09-10T12:55:47.798412746Z [err] [WARN tini (2)] Tini is not running as PID 1 and isn't registered as a child subreaper.

2026-09-10T12:55:47.798417796Z [err] Zombie processes will not be re-parented to Tini, so zombie reaping won't work.

2026-09-10T12:55:47.798423036Z [err] To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.

2026-09-10T12:55:47.798427966Z [inf] Certificate will not expire

2026-09-10T12:55:47.798434505Z [inf] pgbackrest: volume 46626 MiB; sized wal-drop= MiB queue-max=5120 MiB

2026-09-10T12:55:47.798439555Z [inf] pgbackrest: restore-gate WAL_RECOVER_FROM_BUCKET= POSTGRES_RECOVERY_TARGET_TIME= PG_VERSION=present PG_CONTROL=present RESTORED_MARKER=missing PGDATA=/var/lib/postgresql/data/pgdata

2026-09-10T12:55:47.798444745Z [inf]

2026-09-10T12:55:47.798449945Z [inf] PostgreSQL Database directory appears to contain a database; Skipping initialization

2026-09-10T12:55:47.798454515Z [inf]

2026-09-10T12:55:47.798460615Z [err] 2026-09-10 12:55:47.714 UTC [31] LOG: starting PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit

2026-09-10T12:55:47.798465475Z [err] 2026-09-10 12:55:47.714 UTC [31] LOG: listening on IPv4 address "0.0.0.0", port 5432

2026-09-10T12:55:47.798471165Z [err] 2026-09-10 12:55:47.714 UTC [31] LOG: listening on IPv6 address "::", port 5432

2026-09-10T12:55:47.798476095Z [err] 2026-09-10 12:55:47.717 UTC [31] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"

2026-09-10T12:55:47.798481275Z [err] 2026-09-10 12:55:47.724 UTC [69] LOG: database system was shut down at 2026-09-10 12:55:45 UTC

2026-09-10T12:55:47.798485435Z [err] 2026-09-10 12:55:47.737 UTC [31] LOG: database system is ready to accept connections

2026-09-10T12:55:48.598131573Z [inf] Starting Container

2026-09-10T12:55:49.865924377Z [inf] collation-refresh: psql:/tmp/collation-refresh.SV8wsz.sql:16: NOTICE: version has not changed

2026-09-10T12:55:49.865931137Z [inf] collation-refresh: psql:/tmp/collation-refresh.SV8wsz.sql:16: NOTICE: version has not changed

2026-09-10T12:55:49.865946707Z [inf] collation-refresh: psql:/tmp/collation-refresh.SV8wsz.sql:16: NOTICE: version has not changed

2026-09-10T13:00:49.968630572Z [err] 2026-09-10 13:00:47.824 UTC [67] LOG: checkpoint starting: time

2026-09-10T13:00:49.968638002Z [err] 2026-09-10 13:00:47.844 UTC [67] LOG: checkpoint complete: wrote 0 buffers (0.0%), wrote 2 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=0.004 s, sync=0.002 s, total=0.021 s; sync files=3, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB; lsn=0/4429A00, redo lsn=0/44299A8

Logs don't seem to contain any errors. Can you do one more normal redeploy of the database service, wait for it to finish, then open the database tab again?

2026-09-10T13:15:08.637772594Z [inf] Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/6433ed50-c496-425a-929f-c35e787c9100/vol_5narsjd5js3lmzzc

2026-09-10T13:15:09.043111550Z [inf] pgbackrest: volume 46626 MiB; sized wal-drop= MiB queue-max=5120 MiB

2026-09-10T13:15:09.043111910Z [inf]

2026-09-10T13:15:09.043119590Z [err] 2026-09-10 13:15:08.763 UTC [69] LOG: database system was shut down at 2026-09-10 13:15:05 UTC

2026-09-10T13:15:09.043123350Z [err] 2026-09-10 13:15:08.628 UTC [39] LOG: starting PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit

2026-09-10T13:15:09.043125450Z [inf] pgbackrest: restore-gate WAL_RECOVER_FROM_BUCKET= POSTGRES_RECOVERY_TARGET_TIME= PG_VERSION=present PG_CONTROL=present RESTORED_MARKER=missing PGDATA=/var/lib/postgresql/data/pgdata

2026-09-10T13:15:09.043132110Z [err] 2026-09-10 13:15:08.778 UTC [39] LOG: database system is ready to accept connections

2026-09-10T13:15:09.043134360Z [err] 2026-09-10 13:15:08.741 UTC [39] LOG: listening on IPv4 address "0.0.0.0", port 5432

2026-09-10T13:15:09.043136920Z [inf]

2026-09-10T13:15:09.043145740Z [err] 2026-09-10 13:15:08.741 UTC [39] LOG: listening on IPv6 address "::", port 5432

2026-09-10T13:15:09.043151400Z [err] 2026-09-10 13:15:08.751 UTC [39] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"

2026-09-10T13:15:09.043160410Z [err] [WARN tini (2)] Tini is not running as PID 1 and isn't registered as a child subreaper.

2026-09-10T13:15:09.043174140Z [err] Zombie processes will not be re-parented to Tini, so zombie reaping won't work.

2026-09-10T13:15:09.043179460Z [err] To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.

2026-09-10T13:15:09.043184030Z [inf] Certificate will not expire

2026-09-10T13:15:09.043251739Z [inf] PostgreSQL Database directory appears to contain a database; Skipping initialization

2026-09-10T13:15:09.629579641Z [inf] Starting Container

2026-09-10T13:15:10.659619729Z [inf] collation-refresh: psql:/tmp/collation-refresh.Le1bTn.sql:16: NOTICE: version has not changed

2026-09-10T13:15:10.659623439Z [inf] collation-refresh: psql:/tmp/collation-refresh.Le1bTn.sql:16: NOTICE: version has not changed

2026-09-10T13:15:10.659626319Z [inf] collation-refresh: psql:/tmp/collation-refresh.Le1bTn.sql:16: NOTICE: version has not changed

In variables just use the preset one. I can't remember but you should see a list if you press on the inputbox. This is your app connecting to the database. This is the Db connection url

Your Postgres is fine. The logs show

a normal start and "ready to accept

connections".

The failing part is in your own

screenshot:

Postgres WebSocket tunnel failed to

connect (wss://ssh.railway.com:2226

/ws/tcpip)

The Database tab is a browser client

that tunnels over a WebSocket on port

1. Corporate networks, VPNs and

some browser extensions block that

port, so the tab fails while the

database itself is healthy.

Two checks that separate the two

cases:

1. Try the Database tab from a

   different network (phone hotspot),

   with VPN off and extensions

   disabled.

2. Confirm the database is reachable

   outside the browser:

   railway link

   railway connect Postgres

If the CLI connects and your app runs

normally, nothing is wrong with the

service and redeploying will not help

— it is the tunnel from your browser.

If the CLI also fails, share the exact

error from that command.

Hi,

your Postgres database is actually perfectly healthy and running normally. The log line database system is ready to accept connections confirms the database itself is not the problem.

The issue is entirely a network connection problem between your browser and the Railway dashboard. The "Postgres WebSocket tunnel failed to connect" error means something on your local network or computer is blocking the WebSocket connection on port 2226, which the Railway UI relies on to display the database tab.

Try:

• Change networks: Switch to a mobile phone hotspot. Corporate, university, or public Wi-Fi networks often block non-standard ports like 2226.
• Disable VPNs: Turn off any active VPN connections, as they frequently interfere with WebSocket tunnels.
• Check browser extensions: Disable ad blockers, strict privacy shields, or try accessing the dashboard from a completely clean browser profile (incognito mode sometimes still runs background extensions).

And also try this:

If your network environment strictly blocks port 2226 and you cannot change it, you can bypass the browser entirely and connect directly to your database using the Railway CLI.

1.Link your project:

Open your terminal and run railway link to connect your local environment to your Railway project.

2.Connect to Postgres:

Run railway connect Postgres to open a direct, secure connection to the database from your command line.

Here is how to diagnose and fix this issue:

Restart the Database Service: This is the most common fix for a transient tunnel failure. Go to the Settings tab of your Postgres service, scroll down, and click Restart. Alternatively, you can restart it directly from your project canvas.

Check Metrics for OOM: Even if the deployment status is green, your container might be frozen due to lack of memory (Out of Memory error). Click on the Metrics tab and check if your RAM usage has hit its limit. If it has, you may need to upgrade your project plan or optimize your database queries.

Inspect the Deployment Logs: Click on the Deployments tab and view the deployment logs. Look for any recurring crash loops, fatal Postgres errors, or connection rejections that would cause the container to reject the SSH tunnel.

Verify External Connection: Determine if the database itself is down or if it is just a UI issue. Go to the Variables tab, copy your DATABASE_URL, and attempt to connect using an external database tool like DBeaver, pgAdmin, or the psql command line tool. If you can connect externally, the database is fine and the issue is strictly with Railway's data browser UI.

Check Platform Status: Occasionally, Railway experiences platform-wide issues affecting their proxy networks. Check status.railway.app for any ongoing incidents.