# teams webhook connector 429 throttled

## TL;DR
Teams throttles connector webhooks aggressively, so bursts of posts get 429s. Read the Retry-After header and back off with jitter, batch multiple updates into fewer message cards, and put a rate limiter in front of the sender. Monitor for repeat 429s and tune the send rate until they stop.

```text
teams webhook connector 429 throttled
```

## Use this when

- Teams connector webhook posts return 429
- Notifications fail in bursts but succeed when retried later
- Multiple services share one connector URL and all start failing

## Not for this skill when

- Webhook URL returning 404 (deleted connector, different fix)
- Bot framework message failures (different API and limits)
- A single message failing every time (payload problem, not throttling)

## Steps

### Step 1: Read the Retry-After header

Capture a 429 response and read its Retry-After value. Expected: you know exactly how long Teams wants you to wait.

### Step 2: Back off with jitter

Pause sending for at least the Retry-After duration plus random jitter before retrying. Expected: the retried post succeeds instead of stacking more 429s.

### Step 3: Batch messages

Combine multiple updates into fewer, richer message cards instead of one post per event. Expected: the send rate drops by an order of magnitude.

### Step 4: Add a client-side rate limiter

Queue outgoing posts and cap the send rate per connector URL well under the throttle threshold. Expected: bursts are smoothed and 429s stop appearing.

### Step 5: Monitor and tune

Alert on 429 responses and adjust the limiter if they recur. Expected: a dashboard showing zero throttled posts over a full day.

## Tool compatibility

Microsoft Teams incoming webhooks / Office 365 connectors; message card payloads; any notification service posting to Teams.

## Variant phrasings

### Variant 1

teams incoming webhook 429 too many requests

### Variant 2

microsoft teams connector throttled retry-after

### Variant 3

teams webhook rate limit how many messages per minute

## Why it happens

Teams applies per-connector rate limits to keep noisy integrations from flooding channels, and the thresholds are low enough that normal burst patterns, deploys, alert storms, or several microservices sharing one connector URL, trip them routinely. A 429 is a slow-down signal, not an error to retry immediately, but most senders treat it as a transient failure and retry at full speed, which extends the throttle. The durable fix moves the pacing to the sender: a queue with a fixed send rate turns unpredictable bursts into a smooth stream the connector accepts.

## Edge cases / pitfalls

- Several producers sharing one connector URL share one throttle budget; split URLs or centralize sending.
- Retry storms after an outage can re-trigger throttling just as the backlog clears; drain backlogs slowly.
- Message size also matters; enormous cards can fail where small ones pass, so keep payloads lean.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Fw_InuF7PTsaBrMJk_46Zg