PostgreSQL Error 57P03: Cannot Connect Now
Troubleshoot PostgreSQL Error 57P03 (database system is starting up) with pg_isready, standby recovery, and network checks.
On this page
PostgreSQL SQLSTATE 57P03 is cannot_connect_now. It means the server received the connection attempt but is not accepting this connection at that time. Check whether the server is starting, recovering, or entering standby before changing authentication or network settings. PostgreSQL lists the code in its error-code appendix.
A common client message is FATAL: the database system is starting up. During restart, crash recovery, or standby recovery, this can be a temporary readiness state rather than a bad password or a broken network route.
Check whether PostgreSQL is ready
Use pg_isready with the same host and port as the application:
pg_isready -h db.example.com -p 5432
The exit status helps distinguish server readiness from a network failure:
0: the server is accepting connections.1: the server is reachable but rejecting connections, for example during startup.2: no response was received.3: no connection attempt was made, usually because the command arguments were invalid.
pg_isready checks server status; it does not prove that the application has valid credentials or database privileges. See the official pg_isready documentation.
If the server is starting after a restart or crash, check the service manager or PostgreSQL logs for the startup failure or readiness message. Avoid repeatedly restarting a server that is performing recovery. PostgreSQL explains how to start the server and diagnose startup failures.
Check standby recovery state
A standby does not necessarily accept client connections as soon as its process starts. With hot_standby enabled, PostgreSQL begins accepting read-only connections after recovery reaches a consistent state. Until then, a client may be rejected. Check the standby logs for consistent recovery state reached and database system is ready to accept read-only connections; see PostgreSQL’s hot standby documentation.
If the server is intentionally configured not to accept connections during recovery, wait for recovery or use the correct primary endpoint. Do not route writes to a hot standby: connections accepted during hot standby are read-only.
Distinguish related connection errors
- Error 57P01 (
admin_shutdown): PostgreSQL terminated an existing connection because a shutdown was requested; see Error 57P01 troubleshooting. - Error 57P03 (
cannot_connect_now): PostgreSQL is reachable but is not ready to accept this connection. - No response or “connection refused”: the client did not receive a PostgreSQL error response. Check the host, port, listener, service, firewall, and network route; see the official client connection problems guide.
- Error 53300 (
too_many_connections): the server has no connection slot available. Check PostgreSQL Error 53300. - Error 28P01 (
invalid_password): PostgreSQL accepted the connection request but rejected password authentication. See PostgreSQL Error 28P01.
For managed databases, also check the provider’s maintenance, failover, and readiness status. A startup rejection is normally transient; applications should retry with a bounded delay rather than treating it as a bad password or restarting the database.
Browse the PostgreSQL error troubleshooting index for other SQLSTATE guides.