# Monitoring with index stats
## What to watch
`index.describe_index_stats()` returns total vector count, per-namespace counts, and index fullness. That is your whole observability surface for data health; pair it with your request metrics (latency, error rates, 429 counts) from your client layer.
## Steps
1. **Baseline.** Record totals per namespace right after a known-good ingest. Every alert is a deviation from this baseline.
2. **Alert on drops.** A falling total means deletes or a failed re-ingest. Page on it; silent data loss is the worst failure mode here.
3. **Alert on runaway growth.** Totals climbing faster than ingest jobs explain means a runaway writer or a tenant abusing the API.
4. **Watch fullness on pods.** Approaching capacity degrades and then fails writes. Fullness trending up with no scaling plan is an incident in slow motion.
5. **Track 429 rate** from client logs. Rising throttles precede user-visible latency.
## Traps
1. Monitoring only totals: a per-namespace breakdown catches one tenant's ingest wiping another's data via a wrong-namespace delete.
2. No baseline: without a known-good number, every alert threshold is a guess.
3. Alerting on the console only: pull stats into your own monitoring so they page like everything else.