# Connections spike
Symptom: Atlas Metrics shows Connections climbing; new operations start timing out.
## Diagnose
1. Is it flat at the cap (exhaustion) or climbing without bound (leak)? Flat means demand exceeds pool; climbing means clients are created and never closed.
2. Check currentOp for sessions idle for a long time: idle app servers holding pools open, forgotten mongosh sessions, or tools left connected.
3. Correlate with deploys: a deploy that started creating a client per request shows up as a step change.
## Confirm
Count clients: instances x clients per instance. If the math already exceeds the tier cap, you found it. If the math is fine but the metric disagrees, something is leaking (per-request clients, unclosed change stream cursors, unclosed sessions).
## Fix
- Leak: share one client per process; close sessions and cursors explicitly.
- Idle buildup: lower `maxIdleTimeMS` so idle connections recycle.
- Genuine demand: raise `maxPoolSize` deliberately or scale the tier.
## Verify
Connections settles to the computed ceiling (clients x pool size) and stays there under load. Set an alert on connection count so the next spike pages before it breaks.