HikariPool-1 — Connection is not available, request timed out after 30000ms

What this error actually means

This is a queue timeout, not a database error. A thread asked the pool for a connection, the pool had none free, and the thread waited `connectionTimeout` milliseconds (30 seconds by default) before giving up. The database itself may be completely idle and healthy while this exception floods your logs.

The distinction that matters: the pool is a fixed set of slots, and a slot is only returned when your code closes the connection. So there are exactly two possible states behind this message — either every slot is legitimately busy doing work (saturation), or slots have been borrowed and never given back (a leak). Those two states need opposite fixes, which is why raising the pool size blindly resolves one and makes the other worse.

A leak produces a characteristic signature: the failure appears some number of requests *after* the request that actually caused it, and it never recovers until the process restarts. Saturation, by contrast, tracks traffic — it appears at peak and clears when load drops.

How to diagnose it

spring.datasource.hikari.leak-detection-threshold=20000

SELECT state, count(*), max(now() - state_change) AS longest
FROM pg_stat_activity
WHERE datname = current_database()
GROUP BY state ORDER BY 2 DESC;

curl -s localhost:8080/actuator/metrics/hikaricp.connections.active

The fix

For the leak, make release unconditional. Acquire the connection inside try-with-resources so the close happens on every path, including the ones you did not anticipate. Never call `close()` at the end of a method body and hope no exception fires before it.

For the open transaction, make the transaction boundary explicit and finish it before the connection is released: commit on success, roll back on failure, and only then close. If you are on a framework, the equivalent is to stop manually acquiring the connection at all and let the declarative transaction manager own the whole boundary.

For genuine saturation, stop holding connections across work that does not need the database. Move HTTP calls and heavy in-memory transformation outside the borrow window, then size the pool from measurement rather than intuition: a pool of roughly `(cores * 2) + effective_spindles` per instance, multiplied by instance count, must stay under the database `max_connections` with headroom for migrations and admin sessions. Bigger is very often slower.

For nested acquisition, break the dependency: either one connection travels down with the sub-tasks, or the sub-tasks use a separate pool, or the work is restructured so a holder never waits on a borrower.

// Leaks on any throw between getConnection() and close()
Connection c = dataSource.getConnection();
var rs = c.createStatement().executeQuery(sql);   // throws -> slot gone forever
c.close();

// Release is unconditional, and the transaction ends before the slot returns
try (Connection c = dataSource.getConnection()) {
    c.setAutoCommit(false);
    try (var st = c.prepareStatement(sql)) {
        st.setLong(1, customerId);
        try (var rs = st.executeQuery()) {
            // ... map rows
        }
    }
    c.commit();
} catch (SQLException e) {
    // rollback happens on the same connection before close(); see note below
    throw new DataAccessException(e);
}

How to stop it coming back

• Keep `leakDetectionThreshold` enabled in staging permanently — it costs nothing and catches the bug before production does
• Alarm on `hikaricp.connections.pending > 0` sustained, not on the timeout exception; pending is the early signal and the exception is the aftermath
• Add a test that forces the exception path N+1 times and asserts the pool still serves traffic. Lifecycle bugs are invisible to happy-path tests
• Cap statement time at the database (`SET statement_timeout`) so one pathological query cannot hold a slot indefinitely
• Review any code that acquires a connection outside the framework’s transaction management — that is where these bugs live

FAQ

Related

Other errors engineers hit next to this one

• 502 Bad Gateway from a reverse proxy
• 504 Gateway Timeout
• CORS preflight: missing Access-Control-Allow-Origin
• 413 Payload Too Large
• 429 Too Many Requests and Retry-After
• nginx 499 client closed request
• upstream prematurely closed connection
• Intermittent 502 after an idle keep-alive connection