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

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