Azure Database for PostgreSQL
An Azure managed PostgreSQL database service for app development and deployment.
By doing a database restore to a new instance, I was able to recover almost all of the data.
PostgreSQL flexible instance is not responding
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(208, 91%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ET%3C/text%3E%3C/svg%3E)
themapsmith
0
Reputation points
A burstable PostgreSQL flexible instance is not responding. The server accepts TCP on port 5432 but does not complete the PostgreSQL TLS handshake. A restart did not fix it
Azure Database for PostgreSQL
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(249.60000000000002, 14.000000000000002%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EHE%3C/text%3E%3C/svg%3E)
Harshitha Eligeti 10 Reputation points Microsoft External Staff Moderator2026-04-19T19:02:21.1633333+00:00 Hey there – it sounds like your burstable PostgreSQL flexible‐server is up at the TCP level (port 5432 is listening) but isn’t completing the TLS handshake. Here’s a quick playbook to help you diagnose and resolve it:
- Check server status & health • In the Azure portal, go to your Flexible Server’s Overview → Server status: is it “Ready”? • Under Monitoring → Resource Health: any “PlatformInitiated” or maintenance events showing?
- Verify basic connectivity • From your client box install the PostgreSQL tools and run: pg_isready -h <your-server>.postgres.database.azure.com -p 5432 -U <admin_user> You should see “accepting connections.” • Do an nslookup on the FQDN – make sure DNS resolves to the address listed under Networking in the portal.
- Look at your burstable metrics • Burstable SKUs (B-series) use CPU credits; if credits hit zero, the server will throttle heavily and even TLS handshakes can stall. • In the portal go to Monitoring → Metrics and chart CPU credits remaining, CPU %, active connections. • If credits are exhausted, either boost the tier (General Purpose/Memory Optimized) or switch off any runaway jobs.
- Do a stop/start instead of a simple restart • A stop/start deallocates and reallocates the VM backing your server, which often clears stuck states: az postgres flexible-server stop –-resource-group RG –-name YOURSERVER az postgres flexible-server start –-resource-group RG –-name YOURSERVER
- Review TLS settings & logs • Make sure you’re connecting with sslmode=require (or verify-full) and you haven’t overridden
require_secure_transport. • Pull your server logs from Azure Diagnostics (or use the portal’s Log pane) to see if you get a specific “handshake failed” message. - If it’s still stuck • Try restoring from the latest backup to a new server (under Settings → Backup & restore) and test connectivity there. • If you suspect a platform or maintenance issue, open a support request – your service team can check the backend health.
Hope one of these steps gets your TLS handshake moving again! If not, let me know:
• Which burstable SKU are you on and what do your CPU credits look like?
• Any errors in the server logs during the handshake?
• Are you using the FQDN or a hard-coded IP?
Reference docs
- Stop/Start CLI commands: https://docs.microsoft.com/azure/postgresql/flexible-server#az-cli
- Backup & restore flexible server: https://learn.microsoft.com/azure/postgresql/flexible-server/backup-and-restore
Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.
Sign in to comment
2 answers
Sort by: Most helpful
-
themapsmith 0 Reputation points
2026-04-20T18:53:22.23+00:00 -
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 95%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESD%3C/text%3E%3C/svg%3E)
Saraswathi Devadula 16,025 Reputation points Microsoft External Staff Moderator2026-04-21T04:58:51.6966667+00:00 Hello themapsmith
Glad that restore process helped you in recovering the data with no data loss.
Sign in to comment -
-
Saraswathi Devadula 16,025 Reputation points Microsoft External Staff Moderator
2026-04-20T05:16:06.2466667+00:00 Hello themapsmith
As an alternative to reduce downtime, you may consider performing a Point‑in‑Time Restore (PITR) to restore the database to a new PostgreSQL Flexible Server using a timestamp prior to the issue. This allows you to bring the workload back online sooner while the original server recovery is still in progress.PITR provides a full and consistent restoration of data up to the selected timestamp, with no data loss. This is effectively the same data as the original server, running on clean infrastructure.
Please share the server details with me via the private message for further troubleshooting.