Between 04:12 and 04:54 UTC on 9 August, roughly 30% of API requests returned 503. No data was lost and no customer configuration changed. Here is exactly what happened.
The trigger was a scheduled batch job that opened connections faster than the pool could recycle them. The pool limit had not been touched since 2018, when the service handled a fraction of today’s traffic.
What made it a 42-minute incident rather than a 4-minute one was our alerting: we paged on error rate but not on pool saturation, so the first eleven minutes were spent looking in the wrong place entirely.
