Error text: `QuotaExceededException`, or `The maximum number of ... has been reached`.
Limits that bite:
- **Messaging units (Premium) / throughput units (Standard).** Each unit is a bundle of throughput and connections. Sustained 429s + quota errors = add units: `az servicebus namespace update -g [rg] --name [ns] --sku Premium --capacity 2`.
- **Connections per namespace.** 1,000 (Basic/Standard) to higher on Premium. One AMQP connection per sender/receiver adds up fast in microservices; share clients.
- **Entities per namespace.** 10,000 queues+topics on Premium. Dynamic per-tenant queue creation without cleanup hits this.
- **Message size.** 256 KB Standard, 100 MB Premium (with caveats). Oversize messages fail at send with a clear error; chunk or use claim-check (store payload in Blob, send the reference).
- **Lock duration vs processing.** Not a quota, but the classic companion: lock expires before processing finishes, message redelivers, duplicates spike. Raise lock duration or shrink the work unit.
Diagnose: namespace metrics (throttled requests, connections, CPU) in the portal show which limit is binding. Do not raise units blindly; a connection leak looks like a throughput problem until you check the connection count.