**TL;DR:** QuotaExceededException on Service Bus is a namespace throughput or entity-count limit, not a subscription quota. Scale messaging units or split namespaces; retries will not help.

## The fix

1. **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`.

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.

3. **Entities per namespace.** 10,000 queues+topics on Premium. Dynamic per-tenant queue creation without cleanup hits this.

4. **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).

5. **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.

## When to use this

- This covers exactly what the title says: Azure Service Bus quota.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Azure; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Azure behavior.