🚨 Microsoft Teams Error: 'Microsoft Teams endpoint returned HTTP error 429' — Cause, Fix, and Troubleshooting Guide

What this error means

A Power Automate flow, an Azure Logic App, or a high-volume script posting to a Teams channel starts failing, and the connector action reports:

Microsoft Teams endpoint returned HTTP error 429

This is throttling. The Teams service applies rate limits per connector, per webhook, and per channel. When you push more messages into a channel than the service will accept in a short window, it rejects the surplus with 429 Too Many Requests rather than queueing them. The practical ceiling is low compared to what a tight loop can generate — on the order of a few requests per second, with additional hourly caps per connector/channel. The message text comes from the connector layer wrapping the underlying 429; the fix is to slow down and respect the throttle signal.

How it presents

• A flow or script that ran fine at low volume starts failing once message frequency climbs.
• The connector action output shows Microsoft Teams endpoint returned HTTP error 429.
• Failures cluster: a burst of posts to one channel all fail together, then recover after a pause.
• A Retry-After header (seconds to wait) accompanies the underlying 429 response.
• Fan-out patterns (one flow posting to many channels in a loop) trip the limit fastest.
• Retrying immediately without a delay produces more 429s, not success.

Tracing the connection

When posting directly, capture the status and the Retry-After header so you can see both the throttle and the requested wait:

curl -s -o /dev/null \
  -D - \
  -H "Content-Type: application/json" \
  -d @payload.json \
  "$TEAMS_WEBHOOK_URL" | grep -iE '^HTTP|^Retry-After'

Expect output like:

HTTP/2 429
Retry-After: 30

Count how many posts you are actually sending per minute — throttling usually means the real rate is far higher than intended:

grep 'POST /webhook' app.log | awk '{print substr($0,1,16)}' | uniq -c | sort -rn | head

In Power Automate or Logic Apps, open the failed run, expand the Teams action, and confirm the raw output contains the 429 and any retryAfter value. If concurrency is on, note how many parallel branches posted at once.

Network path causes

• Too many messages to one channel too fast. Per-channel and per-connector rate limits are the primary trigger; a loop without delay saturates them in seconds.
• No backoff on retry. Immediate retries after a 429 extend the throttle window instead of clearing it.
• Ignoring Retry-After. The service tells you how long to wait; not reading the header means you retry too early.
• Unbatched notifications. Sending one message per event (per row, per alert) multiplies request volume that could be aggregated into a single post.
• Concurrency in the flow. A “Apply to each” with concurrency enabled fires many simultaneous posts to the same channel.
• Multiple producers, one channel. Several flows or services all posting to the same channel share the same limit and collectively exceed it.

Remediation steps

The core fix is to send less and to wait when told. When posting yourself, read Retry-After and sleep for that many seconds before retrying, with exponential backoff as a fallback:

post() {
  local attempt=0 max=5
  while :; do
    code=$(curl -s -o /dev/null -w "%{http_code}" -D /tmp/hdr \
      -H "Content-Type: application/json" \
      --data-binary @payload.json "$TEAMS_WEBHOOK_URL")
    [ "$code" != "429" ] && return 0
    wait=$(grep -i '^Retry-After:' /tmp/hdr | tr -dc '0-9')
    wait=${wait:-$((2 ** attempt))}
    attempt=$((attempt + 1))
    [ "$attempt" -ge "$max" ] && return 1
    sleep "$wait"
  done
}

Aggregate before you send. Instead of one post per event, collect events over a short window and send a single card with a list. This is the highest-leverage change because it cuts request count by whatever your batch factor is.

In Power Automate: turn off concurrency on “Apply to each”, add a Delay action between posts, and prefer collecting items into a variable and posting once after the loop. In Logic Apps, add a retry policy that respects Retry-After and lower the flow’s degree of parallelism.

Spread load across channels where it makes sense, and reduce overall frequency for noisy notifications — most alerting does not need sub-second delivery to a channel.

Keeping the path healthy

• Always honor Retry-After. It is the authoritative wait time; guessing shorter just re-throttles you.
• Backoff, do not hammer. Fixed immediate retries turn a transient 429 into a sustained outage of your notifications.
• Batch aggressively. One digest message per minute beats sixty individual posts and stays well under the limit.
• Disable loop concurrency. Parallel “Apply to each” branches are a common hidden cause of bursty throttling.
• Account for all producers. The channel limit is shared; audit every flow and service posting to the same channel.
• Alert on sustained 429s. A steady stream of throttling means the design, not a spike, is over the limit — fix the rate, not just the retry.

Related connectivity errors

• 429 Too Many Requests
• Workflow Action Post Card Failed
• Connector Retirement 410 Gone