Database connection issue

Question

I have two azure container apps and one azure postgres, i am using default pgbouncer from azure

Now theres some problem from my azure container backend app the database connection is taking too long and eventually request time out

but locally i have connected that live database it is working fine

why that is happening in live application, anyone have any clue?

from my live api responce

{
  "success": false,
  "statusCode": 408,
  "message": "Request timed out after 35000ms",
  "messageKey": "http.exception",
  "error": "Request Timeout",
  "stack": "RequestTimeoutException: Request timed out after 35000ms\n    at /app/dist/common/interceptors/timeout.interceptor.js:28:53\n    at Observable.init [as _subscribe] (/app/node_modules/rxjs/dist/cjs/internal/observable/throwError.js:8:64)\n    at Observable._trySubscribe (/app/node_modules/rxjs/dist/cjs/internal/Observable.js:41:25)\n    at /app/node_modules/rxjs/dist/cjs/internal/Observable.js:35:31\n    at Object.errorContext (/app/node_modules/rxjs/dist/cjs/internal/util/errorContext.js:22:9)\n    at Observable.subscribe (/app/node_modules/rxjs/dist/cjs/internal/Observable.js:26:24)\n    at /app/node_modules/rxjs/dist/cjs/internal/operators/catchError.js:17:31\n    at OperatorSubscriber._this._error (/app/node_modules/rxjs/dist/cjs/internal/operators/OperatorSubscriber.js:43:21)\n    at Subscriber.error (/app/node_modules/rxjs/dist/cjs/internal/Subscriber.js:60:18)\n    at /app/node_modules/rxjs/dist/cjs/internal/operators/timeout.js:41:32",
  "path": "/health/ready",
  "method": "GET",
  "timestamp": "2026-06-20T04:17:18.192Z",
  "correlationId": "ba4e4e0d-55e1-4f38-befe-5f86a8cc85b1"
}

but locally it is working fine

{
  "success": true,
  "statusCode": 200,
  "message": "Readiness status fetched successfully",
  "data": {
    "status": "ready",
    "timestamp": "2026-06-20T04:04:43.160Z",
    "components": {
      "database": {
        "status": "up",
        "latencyMs": 629
      },
      "authorization": {
        "status": "up"
      }
    }
  },
  "path": "/health/ready",
  "method": "GET",
  "timestamp": "2026-06-20T04:04:43.160Z",
  "correlationId": "3c56bfc7-556e-4caa-9f76-0325eb792e6a"
}

please help me to recover the issue

Answer 1

Hello Md Azimul Islam Sheblu,

Greetings! Thanks for raising this question in Q&A forum.

The classic reason this happens, when local connects fine but your Container App times out, is that the network path from your laptop to Postgres is allowed, but the network path from the Container App to Postgres is not. Your app is not getting an error back, it is just timing out at 35 seconds, which means the connection attempt is hanging rather than being actively rejected. That hanging behavior is the typical sign of a firewall or network rule silently dropping the packets rather than a credentials or pool exhaustion problem.

Here is a simple way to narrow it down and fix it.

Confirm whether it is networking or something deeper From inside one of your Container App containers (use the Container Apps console/exec feature in the portal), run a basic TCP check to the database host and port, for example nc -zv yourserver.postgres.database.azure.com 5432 (or 6432 if you are pointing at PgBouncer). If this hangs and times out, the problem is purely network level, not PgBouncer, not pooling, not your query. If it connects instantly but psql with credentials still fails, then it is an auth or PgBouncer pool issue instead.

Check how your Postgres server is exposed If your PostgreSQL flexible server uses public access with firewall rules, the rule that lets your local machine in is almost certainly your home or office IP. Azure Container Apps egress traffic from a different, often dynamic, outbound IP, so unless that specific IP (or "Allow public access from any Azure service within Azure" type rule) is added to the Postgres firewall, the Container App's connection attempts get silently dropped while your laptop sails through.

Add the right access for the Container App If you want a quick fix, get your Container App's outbound IP and add it as an explicit firewall rule on the Postgres server. If your Container Apps environment does not have a stable outbound IP (common on the Consumption plan without VNet integration), this quick fix will not be reliable long term.

Move to private networking for the real fix The properly supported, more stable setup for two Container Apps talking to one Postgres server in production is VNet integration for your Container Apps environment plus a private endpoint or private access for the Postgres server, so traffic never goes over the public internet or through IP based firewall rules at all. This removes the whole class of intermittent timeout issues caused by changing outbound IPs.

Once networking is confirmed working, then look at PgBouncer After the basic TCP test succeeds reliably from inside the container, if you still see slow connections under load, that is when it is worth checking pgbouncer.max_client_conn and pgbouncer.default_pool_size in the server parameters, and running SHOW POOLS on the PgBouncer admin port to see if connections are queuing.

You can find the setup guidance here: https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-firewall-rules https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-networking-private

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.

Answer 2

Hi @Md Azimul Islam Sheblu ,

Thank you for sharing the detailed logs.
Based on what you've described, your live Container Apps are hitting DB connection-related delays and the app then returns HTTP 408 – Request timed out after 35000ms on the /health/ready endpoint. Since it works locally against the same "live" database, this strongly points to an environment/network/timeout mismatch in the live path, or a transient connectivity event (maintenance, scaling, failover, or resource pressure) that briefly breaks DB connectivity long enough for your readiness probe to fail.

1. Firewall / network rules (including PgBouncer port). A frequent cause of Azure-to-DB timeouts is firewall rules not allowing traffic from the live app environment. Confirm the PostgreSQL firewall allows the source traffic from your Container Apps (including proxies/gateways), that outbound port 5432 is open, and — if you use PgBouncer — that port 6432 is open end-to-end (firewalls + NSGs). Even though it connects locally, the live containers come from a different outbound IP/subnet/gateway, so allowlists can behave differently.
2. Transient events on the PostgreSQL server. Azure may perform maintenance or you may hit brief infrastructure disruptions. Check Azure Resource Health and the Activity log around the failure window. If the server restarts or scales, all connections can drop briefly. Azure mitigates most transient events automatically, usually in under 60s, but the app can still time out if it isn't retrying.
3. Application/client timeout settings (your readiness check is timing out). Your app returns 408 after 35 seconds, meaning the readiness logic waits for DB connectivity longer than the live path can provide during a transient blip. Review your connection timeout, query timeout, and readiness probe timeout, and implement retry with exponential backoff instead of treating the first failure as a hard readiness failure.
4. Connection limits / resource saturation. If the database is near its limits (CPU, memory, or connection slots), new connections can stall or fail. Check PostgreSQL metrics for CPU, memory, and active_connections, and whether you're nearing the maximum connections for your tier. If so, lean on a connection pooler such as PgBouncer (which you already use) and reduce idle/concurrent connections.

Quick steps

1. Correlate timestamps — compare your live timeout times with Resource Health and the PostgreSQL Activity log.
2. Test from the same live environment — from inside the Container App (or a debug container in the same network), test connectivity to PostgreSQL on port 5432 and PgBouncer on port 6432.
3. Verify outbound IP/subnet — confirm the IPs used by the live Container Apps are actually allowed in the PostgreSQL firewall rules.

Follow-up details that help pinpoint faster

1. Which service is it — Flexible Server, Single Server, or Cosmos DB for PostgreSQL?
2. Are you connecting directly or via the PgBouncer endpoint (5432 vs 6432)?
3. Are the Container Apps in the same region as the database?
4. Did anything change around the failure window — server restart, vCore/tier scaling, AZ/region change, or container redeploy?
5. Can you share the (sanitized) DB connection/query timeout values from the live config?

Reference Documentation

• Troubleshoot connection issues to Azure Database for PostgreSQL: https://learn.microsoft.com/en-us/azure/postgresql/troubleshoot/how-to-troubleshoot-common-connection-issues
• Handling transient connectivity errors (retry logic): https://learn.microsoft.com/en-us/azure/postgresql/troubleshoot/concepts-connectivity
• Limits in Azure Database for PostgreSQL (max connections): https://learn.microsoft.com/en-us/azure/postgresql/configure-maintain/concepts-limits
• PgBouncer in Azure Database for PostgreSQL: https://learn.microsoft.com/en-us/azure/postgresql/connectivity/concepts-pgbouncer

Hope this helps. If you can confirm Flexible vs Single Server and whether you're targeting PgBouncer port 6432, I can suggest the most likely specific fix. If this resolves your issue, please click Accept Answer so it helps other community members.

Answer 3

The behavior difference between local and Azure Container Apps indicates a connectivity or resource issue between the container app environment and Azure Database for PostgreSQL (with built-in PgBouncer), not with the database itself.

Use the following focused checks and mitigations:

1. Verify the app is actually using PgBouncer (port 6432)
   • Built-in PgBouncer is enabled on port 6432 and uses the same host name as the PostgreSQL server.
   • In the container app connection string, ensure the port is 6432 (PgBouncer) rather than 5432 if PgBouncer is intended:
     • Example test from a shell:

              psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=postgres user=myUser password=<password> sslmode=require"
       

   • If 6432 is unreachable from the container, the app may hang until timeout.
2. Check for transient connectivity issues from the container app
   • Azure Database for PostgreSQL can have transient errors (brief disconnects) due to maintenance, scaling, or infrastructure events.
   • Applications must implement retry logic and handle short connection losses instead of failing after a single long wait.
   • From the app logs, check if timeouts correlate with maintenance windows or scaling events.
3. Check for persistent connectivity issues (network/firewall)
   • From the container app environment:
     • Confirm outbound connectivity to the database host and port (5432 or 6432, depending on what is used).
   • Validate:
     • The server firewall for Azure Database for PostgreSQL allows the container app’s outbound IP or VNet/subnet.
     • Any client-side firewall or network appliance between Container Apps and the database allows outbound traffic on port 5432 and/or 6432.
   • If local connections succeed but the container app times out, this often indicates a firewall or networking rule missing for the container environment.
4. Confirm PgBouncer configuration and limits
   • PgBouncer is enabled/controlled via server parameters:
     • pgbouncer.enabled must be true to use it.
     • pgbouncer.max_client_conn and pgbouncer.default_pool_size control how many connections are allowed.
   • If the container app opens many connections or there are multiple apps, PgBouncer may hit limits and queue connections until the app times out.
   • In the Azure portal → PostgreSQL server → Parameters, review:
     • pgbouncer.max_client_conn (default 5000)
     • pgbouncer.default_pool_size (default 50 per user/database pair)
   • If the app is highly concurrent, consider tuning these values.
5. Monitor PgBouncer from the server side
   • Connect to the PgBouncer admin console and inspect pools and stats:

          psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=pgbouncer user=myUser password=<password> sslmode=require"
     

   • Run:
     • SHOW POOLS; to see active/idle/waiting connections.
     • SHOW DATABASES; to see connection limits per database.
     • SHOW STATS; to see traffic and request stats.
   • If many clients are waiting or pools are saturated, the app’s requests may be blocked until they hit the 35s timeout.
6. Check for resource limits and long-running queries
   • If the server is near its resource limits (CPU, connections, I/O), connections and queries can appear to hang.
   • Use PostgreSQL monitoring (e.g., pg_stat_activity) and Azure metrics to see if connections are piling up or queries are long-running.
7. Ensure proper retry and timeout strategy in the app
   • For cloud databases, implement:
     • Shorter connect timeouts with retry logic for transient failures.
     • Reasonable query timeouts so a single slow query does not block the health endpoint for 35 seconds.
   • The health/ready endpoint should perform a lightweight query to minimize latency.
8. If issues persist beyond ~60 seconds or recur frequently
   • If timeouts continue or last longer than typical transient events, and resource/network checks look healthy, open an Azure support request via Get Support so the platform team can check backend logs and regional health.

---

References:

• PgBouncer in Azure Database for PostgreSQL
• Troubleshoot connection issues to Azure Database for PostgreSQL
• Troubleshoot connection issues to Azure Cosmos DB for PostgreSQL
• Connection pooling strategy for Azure Database for PostgreSQL using PgBouncer
• PostgreSQL troubleshooting