The throttle signatures
Throttling is designed to look like mild degradation, not failure — hence misread as 'Exchange is slow':
| Signature | Limit |
|---|---|
| Scripted sender DEFERs at a steady rate | Message-rate (30/min) |
| Campaign dies partway | Recipient-rate (10k/day) — wrong pipe (HVE/ACS) |
| One send → hundreds of NDRs | Recipients-per-message cap |
| Bulk read slows/errors mid-run | EXO cmdlet throttling |
| Migration throughput plateaus | MRS throttling both sides |
| Graph app gets 429s | Service-protection limits — honour Retry-After |
The tell vs OUTAGE: throttling is rate-shaped and PARTIAL (some succeed, metronomically); outages are binary and advisory-backed. A slowdown with no advisory and a suspicious per-minute rhythm is a limit, not Microsoft's bad day.
Why 'raise it' rarely works
Most limits are fixed anti-abuse rails, not dials — their job is stopping compromised-account blasts (reputation concept). The fixes: right pipe (HVE/ACS/Graph — apps hitting mail limits are on the wrong road), throttle-aware code (honour Retry-After, back off, batch — next concept), spread the work (stagger, off-peak, page politely).
What to watch (proofs)
- The rhythm test: metronomic (throttle) vs flat (outage) via DEFER intervals / script timing — the triage that stops wrong escalations.
- Retry-After counts in automation logs — rising = redesign pace before the service does it for you.
- Pipe-mismatch census: senders hitting limits mapped to their correct pipe — the migration backlog that ends the incidents.
- Advisory correlation first, always — theirs vs yours in one glance.