# Teams Webhook Rate Limit Queue Drain Time Calculator

> Source: https://netray.co/tools/teams-webhook-rate-limit-queue-drain-time-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Calculate how long a burst of alerts takes to drain through a rate limited Teams endpoint, including retries after throttling responses.

## Category

developer

## Audience

- Integration developer
- ERP administrator
- IT operations

## Tool

**Kind:** calculator

**Inputs:**

#### Messages in the burst

**Key:** burst

**Type:** number

**Default:** 600

**Min:** 0

**Step:** 50

**Unit:** messages

**Help:** For example a nightly MRP exception run that posts one card per exception.

#### Allowed rate per endpoint

**Key:** rate

**Type:** number

**Default:** 4

**Min:** 0.1

**Step:** 0.5

**Unit:** msg/sec

**Help:** Take this from current Microsoft documentation and your own tests. Limits change.

#### Parallel endpoints

**Key:** endpoints

**Type:** slider

**Default:** 1

**Min:** 1

**Max:** 20

**Step:** 1

**Unit:** endpoints

**Help:** Separate webhooks or workflows posting to separate channels.

#### Messages needing a resend

**Key:** retry_pct

**Type:** slider

**Default:** 10

**Min:** 0

**Max:** 60

**Step:** 1

**Unit:** %

**Help:** Share that hit throttling and must be retried.

#### Exceptions combined per card

**Key:** batch

**Type:** number

**Default:** 1

**Min:** 1

**Step:** 1

**Unit:** per card

**Help:** Digest cards group several exceptions in one message.

**Outputs:**

#### Cards to post

**Key:** cards

**Expr:** ceil(burst / batch)

**Format:** integer

#### Posts including retries

**Key:** effective

**Expr:** cards * (1 + retry_pct / 100)

**Format:** integer

#### Capacity per hour

**Key:** capacity

**Expr:** rate * endpoints * 3600

**Format:** integer

#### Time to drain

**Key:** drain_min

**Expr:** effective / (rate * endpoints) / 60

**Format:** minutes

**Primary:** true

#### Time to drain in seconds

**Key:** drain_sec

**Expr:** effective / (rate * endpoints)

**Format:** number

#### Share of hourly capacity used

**Key:** share

**Expr:** effective / capacity * 100

**Format:** percent

**Primary:** true

**Chart:**

#### Drain time vs parallel endpoints

**Type:** line

**X:** endpoints

**From:** 1

**To:** 20

**Steps:** 20

**Series:**

- drain_min

**Disclaimer:** Teams and Power Automate limits differ by plan and change over time. Confirm the current limit before sizing.

## Content

**Intro:** Posting ERP exceptions, approvals or machine alerts into Teams works until a burst arrives and the endpoint answers with throttling errors. This calculator shows how long the queue takes to clear and whether batching or more endpoints is the better fix.

**Sections:**

#### How to use it

**Body:** Enter the size of your largest burst, not the average. For an ERP that is typically a scheduled job such as an MRP run, a nightly inventory reconciliation or a month end close. Add the per endpoint rate you have measured or read from Microsoft documentation, the number of parallel webhooks or workflows you can split across, and the share of calls that get retried. Setting exceptions per card above one models digest cards.

**Bullets:**

- Size for the biggest burst of the week
- Measure the real rate with a test channel first
- Split by plant or team, not randomly, so channels stay readable

#### Formula and reading the result

**Body:** Cards equal burst divided by exceptions per card, rounded up. Posts including retries equal cards times one plus the retry share. Drain time equals posts divided by rate times endpoints. If 600 exceptions go out one per card at 4 per second with 10 percent retries, that is 660 posts and about 2.75 minutes. The percent of hourly capacity used shows whether you are close to the ceiling when other flows share the same endpoint.

#### Common mistakes

**Body:** Retrying immediately makes throttling worse, so respect the Retry-After header and use exponential backoff. Posting one card per exception floods a channel and trains people to mute it. A digest card with a count and a link to the ERP list is usually kinder to both the endpoint and the readers. Also queue messages in your integration layer instead of in the ERP job, so a slow Teams call never blocks the ERP.

**Bullets:**

- Honor Retry-After before the next call
- Prefer a digest when more than a handful of items arrive together
- Keep the queue outside the ERP transaction

**Cta:** If you want ERP alerts routed to Teams through a queued, private integration with throttling handled properly, Netray can design and run it with you.

**Faq:**

#### What is the Teams webhook rate limit?

**Answer:** It varies by connector type and plan and Microsoft changes it. Look up the current figure in Microsoft documentation and confirm it with a load test, then enter it as the rate here.

#### Does batching really help?

**Answer:** Yes. Combining ten exceptions into one card cuts posts by about ten times and makes the channel readable. The trade-off is less detail per card, so link each card to the ERP exception list.

#### Should I use more webhooks to beat the limit?

**Answer:** Splitting by plant or topic is fine and the chart shows the gain. Spreading one flow across many hooks only to evade throttling is fragile and may breach usage policy, so prefer batching first.

#### Does this cover Slack or other chat tools?

**Answer:** The arithmetic is generic. Replace the rate with the target platform's documented limit and the result holds.

## Search terms

teams webhook rate limit, teams incoming webhook 429, teams power automate workflow throttling, send erp alerts to teams, teams message throughput, teams notification queue

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json