# Diagnose a 429 spike

## Introduction

When callers see `429` from a pool, Metrics plus Logs usually answer why in under
two minutes. You do not need to export NDJSON first.

## Steps

1. Open the pool's **Metrics** tab and set the range to the incident window
   (clamped to your plan retention).
2. Check **Outcomes**. A jump in `overloaded` or `queue_timeout` means the
   concurrency limit or queue budget filled. A jump in `rejected_auth` or `rejected_ip`
   is not capacity.
3. Open **Top keys (overload)** and click a noisy key to jump into **Logs** with
   that filter.
4. Confirm **Live queue** depth and effective limit on Metrics. If depth is high
   while the limit looks right, raise queue timeout or concurrency only after
   you know which callers are burning slots.
5. If you only care about allowance spend, open [Billing](/docs/billing) instead.
   Metrics is admit/queue/reject proof; Billing is request allowance.

## Related

- [Metrics](/docs/pools/metrics)
- [Admission errors](/docs/knowledge-base/admission-errors)
- [Logs](/docs/pools/logs)