PgBouncer server_lifetime recycling waves: synchronized reconnects and capacity dips

Your dashboards show a repeating pattern: every hour (or whatever server_lifetime is set to), sv_login spikes, sv_idle drops, and there is a brief bump in cl_waiting or avg_wait_time. It lasts seconds to a couple of minutes, then everything is green again. Application latency ticks up at the same moment. It looks like a flaky backend, but PostgreSQL is fine and the timing is suspiciously regular.

This is the server_lifetime recycling wave. PgBouncer closes each server connection once it has been connected longer than server_lifetime (default 3600 seconds) and opens a replacement. If a large share of your server connections were created at roughly the same moment, which is exactly what happens after a PgBouncer restart, a PostgreSQL failover, or a cold start under load, they all hit the lifetime limit together and reconnect in lockstep. The pool briefly runs short on backend connections while the replacements authenticate.

The wave is self-inflicted, predictable, and fixable. It is also easy to misread as an incident, and easy to make worse with a well-intentioned server_idle_timeout setting.

What this means

server_lifetime exists to bound how long PgBouncer holds a backend connection. Recycling is useful: it prevents indefinite connection age, picks up DNS changes, and redistributes connections across backends. The problem is not the recycling itself but the synchronization.

The trigger is almost always one of these:

• PgBouncer restart. All server connections are re-established in a tight window as traffic arrives. One server_lifetime later, they all expire together.
• PostgreSQL restart or failover. Every existing server connection dies at once and is recreated at once.
• Cold start under burst load. A traffic spike creates a large batch of new server connections within seconds of each other.

The dip is usually brief: the pool loses some fraction of its server connections for the time it takes to reconnect and authenticate, then recovers. But if authentication is slow (SCRAM with many simultaneous logins, TLS handshakes, a loaded backend), the reconnect burst itself becomes the bottleneck and the dip deepens into real queuing.

One mitigating behavior worth knowing: lifetime disconnects are spaced by roughly server_lifetime / pool_size seconds per pool, precisely to avoid reconnect floods. This spreads a full pool’s recycling across one lifetime period rather than firing all closes in the same instant. It softens the wave but does not eliminate it: with connections created in a tight cluster, you still see a rolling window of reconnects, an sv_login blip, and a sag in available connections. A side effect of the spacing logic is that in the worst case a connection can live close to 2x server_lifetime before being closed.

flowchart TD
    A[Restart, failover, or cold-start burst] --> B[Many server connections created in a tight window]
    B --> C[Connections age together]
    C --> D[All hit server_lifetime in the same window]
    D --> E[Synchronized close and reconnect]
    E --> F[sv_login spike, sv_idle dip]
    F --> G[Brief capacity dip: cl_waiting and avg_wait_time bump]
    G --> H[Pool recovers... and the cohort repeats every server_lifetime]
    H --> C

Recycling wave vs real incident

Before tuning anything, confirm you are looking at recycling and not at a backend problem that happens to be periodic. The distinguishing tests are periodicity and the direction of the server connection counts.

The strongest tell: measure the interval between dips. If it matches server_lifetime and the first dip happened roughly one lifetime after the last PgBouncer or PostgreSQL restart, you have a recycling wave.

Quick checks

All read-only, run against the admin console.

# Confirm the configured lifetime and idle timeout
psql -h 127.0.0.1 -p 6432 -U pgbouncer pgbouncer -Atc "SHOW CONFIG;" | grep -E "server_lifetime|server_idle_timeout|min_pool_size|default_pool_size|reserve_pool"

# Watch pool states during a suspected wave: sv_login blip, sv_idle dip
psql -h 127.0.0.1 -p 6432 -U pgbouncer pgbouncer -Atc "SHOW POOLS;"

# Inspect connection ages: a synchronized cohort shows many connections
# with nearly identical connect_time
psql -h 127.0.0.1 -p 6432 -U pgbouncer pgbouncer -c "SHOW SERVERS;"

# Rule out maintenance state before treating any dip as an incident
psql -h 127.0.0.1 -p 6432 -U pgbouncer pgbouncer -Atc "SHOW DATABASES;"

# Check queuing pain during the dip
psql -h 127.0.0.1 -p 6432 -U pgbouncer pgbouncer -Atc "SHOW STATS_AVERAGES;"

Two things to look for in SHOW SERVERS: the state column (a wave shows a cluster of connections in login while others flap) and connect_time. If a large fraction of your server connections share nearly the same connect_time, they were born together and will die together. That is the cohort.

How to diagnose it

1. Get the configured values. From SHOW CONFIG, note server_lifetime, server_idle_timeout, default_pool_size, and any per-database pool_size overrides. Also check min_pool_size.

2. Confirm periodicity. Compare the observed dip interval against server_lifetime. Check whether the phase aligns with the last PgBouncer restart, PostgreSQL restart, or failover. The first wave arrives roughly one lifetime after the mass creation event.

3. Check the cohort. In SHOW SERVERS, eyeball connect_time. A tight cluster of identical ages confirms synchronized creation. After a wave passes, look again: the ages will have reset together, which is how the wave perpetuates itself.

4. Measure the actual impact. During a dip, sample SHOW POOLS a few times: how far does sv_idle fall, does cl_waiting go above zero, what does maxwait reach? Check avg_wait_time in SHOW STATS_AVERAGES. If the dip costs a few seconds of slightly reduced headroom and zero waiters, it is cosmetic. If maxwait climbs into seconds, the wave is hurting users and worth fixing properly.

5. Check the reconnect cost. If sv_login stays elevated for more than a few seconds during the wave, reconnection itself is slow: TLS handshakes, SCRAM computation under many simultaneous logins, or an overloaded backend. A slow reconnect path turns a cosmetic blip into a real capacity dip, and it gets worse as the cohort grows.

6. Audit server_idle_timeout. If it is set aggressively low, you may have the opposite pathology layered on top: idle connections destroyed during quiet periods, then recreated on demand when traffic returns, adding connection establishment latency to the first queries of every burst. Check whether sv_idle collapses during troughs and rebuilds during peaks.

Metrics and signals to monitor

Fixes

Stagger the lifetimes

The goal is to decorrelate connection ages so recycling arrives as a trickle instead of a wave.

• Use a non-round lifetime value. The classic operator practice is a prime number (for example, 3599 instead of 3600). The point is not primality itself but avoiding a value that aligns with other periodic events in your system: cron jobs on the hour, connection pool max-lifetime settings in your application, monitoring scrape intervals. Two synchronized clocks beat as one; a value that shares no common period with your other timers keeps the wave from re-synchronizing with traffic patterns.
• Stagger per database. Since PgBouncer 1.23.0, server_lifetime can be set per database in the [databases] section. Giving each pool a different lifetime (for example 3300, 3600, 3900) means no single moment recycles more than one pool’s cohort.

Retune the lifetime itself

• Shorter lifetime, smaller waves. A lower server_lifetime recycles more often but in smaller, more frequent events that the built-in spacing smooths out more effectively. It also redistributes connections across load-balanced backends faster. The cost is more connection churn against PostgreSQL.
• Longer lifetime, rarer but bigger waves. Raising it reduces churn frequency but each wave touches the same cohort when it fires. This trades frequency for amplitude; it does not fix synchronization.
• Do not set it to zero expecting “never recycle.” server_lifetime = 0 means the connection is closed after first use, which is maximum churn, not minimum.

Fix the idle-timeout churn

If server_idle_timeout (default 600 seconds) is set very low, the pool sheds idle connections during quiet periods and pays reconnection latency when traffic returns. Set it high enough that your normal traffic troughs do not drain the pool, or set min_pool_size so a warm floor of connections is always maintained. Note that server_idle_timeout does not close connections when the pool is at or below min_pool_size, so the two settings work together: a sensible min_pool_size protects you from an aggressive idle timeout.

Reduce the cost of each reconnect

If the wave hurts because reconnection is slow, attack the reconnect path: check TLS handshake overhead, whether the backend is loaded during the wave window, and whether authentication is the bottleneck. A wave that closes 20 connections and reopens them in 200 ms is invisible; the same wave with a 3-second auth path is an outage.

Break the cohort at the source

After any event that mass-creates connections (restart, failover), the cohort persists until you break it. A RELOAD does not recreate server connections, so it will not help or hurt here. Where operationally acceptable, rolling restarts of multi-process PgBouncer deployments (one process at a time, spaced apart) naturally stagger connection ages across processes. Otherwise, accept the first wave after a restart as expected behavior, verify it is benign, and let per-database staggered lifetimes decorrelate subsequent ones.

Prevention

• Treat post-restart waves as expected, then eliminate them. The first server_lifetime period after any restart will produce a synchronized recycle. Verify it stays cosmetic, then apply the staggering fixes so later periods are smooth.
• Set server_lifetime to a non-round value by default in your configuration management, and use different values per database on 1.23.0 or later.
• Keep server_idle_timeout conservative and pair it with min_pool_size so quiet periods do not drain the pool.
• Alert on impact, not on the wave. Alerting on sv_login > 0 will page you every lifetime period. Alert on maxwait and sustained cl_waiting (with paused/disabled state checked), which only fire when recycling actually starves clients.
• Watch the cohort after restarts. A quick SHOW SERVERS review of connect_time clustering after any restart or failover tells you whether a wave is scheduled in your future.

How Netdata helps

• Periodicity made visible. Netdata charts sv_login, sv_idle, and per-pool connection states at per-second resolution, so a repeating hourly blip stands out immediately against aperiodic backend failures.
• Cohort impact correlation. Overlaying sv_login with cl_waiting and maxwait on one dashboard answers the only question that matters: did the recycling wave actually starve clients, and by how much.
• Wait vs query time separation. Netdata tracks avg_wait_time and avg_query_time independently, so you can confirm the dip is pooling friction (wait time bump, flat query time) rather than PostgreSQL slowing down.
• Restart correlation. Because Netdata also monitors process uptime and system events on the same host, aligning the wave phase with the last PgBouncer restart is a two-chart comparison.
• Alert hygiene. Alert on sustained maxwait and queue depth rather than transient sv_login activity, which keeps the benign recycling wave from paging you while still catching waves that turn into real capacity dips.

Related guides

• How PgBouncer actually works in production: a mental model for operators
• PgBouncer monitoring checklist: the signals every connection pooler needs
• PgBouncer capacity planning: runway for pools, clients, and PostgreSQL slots
• PgBouncer avg_wait_time high: the latency the pool itself is injecting
• PgBouncer maxwait high: the oldest client waiter and how close it is to timing out
• PgBouncer backend unreachable: PostgreSQL down and the pool draining