Try adding pool_pre_ping=True and pool_recycle=259 to your create_async_engine() call. So that it detects and replaces dead connections before your app tries to use them.

Your occasional asyncio.TimeoutError during SSL Handshakes are occurring due to Railway infrastructure bandwidth throttling/connection pooling limits being reached, not because your SSL certificate expired.

Your FastAPI backend and PostgreSQL DBs are both hosted on Railway so when you get these timeouts it means your backend cannot successfully make an SSL tunnel to your Postgres DB and the packet is being dropped during network handshake. Because this occurs regularly during morning/evening hours, you are likely experiencing peak traffic to your application. When your application scales out to multiple async workers all trying to connect to the DB at the same time, your Railway internal network or single Postgres instance will reach a concurrency limit for open connections and begin dropping them.

How to fix/make better:

Connection Limits: Login to your Railway Postgres dashboard and check your current plan's maximum amount of allowed concurrent connections are not being hit during peak request times.

Client Pool Settings: Open backend/app/db/session.py and double check your asyncpg pool settings are not too aggressively opening minimum connections or thrashing connections. Tune your max_ size.

SSL Parameters: Since the connection cannot successfully complete the SSL handshake you can adjust ssl parameters on your connection string (i.e. ssl=require) or even try adjusting SSL-handshake TCP timeouts within asyncpg itself).

Railway? : If your DB is receiving normal levels of requests/responses then latency in routing between your app <-> DB on Railway is also possible. This will likely require opening a support ticket.

asyncpg does connection pooling natively so misconfiguration here can easily cause timeout cascades.

We investigated the issue and implemented several improvements to the database connection management:

• Increased the connection pool size from the default 5 connections to 20 connections, with an additional 10 overflow connections available when needed.
• Increased the connection timeout from 10 seconds to 30 seconds.
• Enabled pool_pre_ping to automatically detect and replace stale or closed connections before they are used.
• Enabled pool_recycle to refresh connections every hour and prevent long-lived connection issues.

Since applying these changes, the intermittent connection timeout errors have not reoccurred, and the application has been operating normally. The issue appears to have been related to connection pool exhaustion and/or stale database connections under load.