Go to Slack

Rate Limits

Most aspects of the Slack platform are rate limited one way or another, helping provide a predictably pleasant experience for users.

Given the variety of different kinds of inbound and outbound APIs made available, how and when rate limiting occurs differs between features.

The rate limits described in this document will gradually take effect the week of March 7th, 2018. Learn more in our changelog.


Broadly, you'll encounter limits like these, applied on a "per app per workspace" basis.

Feature/API Limit Note
Posting messages 1 per second short bursts >1 allowed
Web API methods 1-100+ requests per method per workspace per minute Each method assigned a rate limit tier. All methods support bursting
Incoming webhooks 1 per second short bursts >1 allowed
Events API events 30,000 deliveries per hour per workspace. Larger bursts are sometimes allowed.
Outgoing webhooks 1 per second short bursts >1 allowed

Web API rate limiting

Your app's requests to the Web API is evaluated per method and per workspace. Rate limit windows are per minute.

Each Web API method is assigned one of four rate limit tiers, with Tier 1 provided the fewest requests and Tier 4 the greatest. There is also a special tier for less classifiable rate limit behavior, special to a method.

The Facts section of each method's reference documentation will indicate its rate limit tier.

Use these ballpark ranges below to plan your application's usage.

Web API rate limit tiers

Tier Range Description
Tier 1 1+ per minute Access tier 1 methods infrequently. A small amount of burst behavior is tolerated.
Tier 2 20+ per minute Most methods allow at least 20 requests per minute, while allowing for occasional bursts of more requests.
Tier 3 50+ per minute Tier 3 methods allow a larger number of requests and are typically attached to methods with paginating collections of conversations or users. Sporadic bursts are welcome.
Tier 4 100+ per minute Enjoy a large request quota for Tier 4 methods, including generous burst behavior.
Special Varies Rate limiting conditions are unique for methods with this tier. For example, chat.postMessage generally allows posting one message per second per channel, while also maintaining a workspace-wide limit. Consult the method's documentation to better understand its rate limiting conditions.

Each tier's limits are subject to change.

Pagination specialness

The tiers reported for methods supporting cursored pagination represent the rate limit when using pagination. You'll receive stricter rate limits When not using pagination — in other words, you'll experience lower rate limits when trying to repeatedly fetch all of users.list without pagination.

Responding to rate limiting conditions

If you go over these limits when using our HTTP based APIs, including Incoming Webhooks, Slack will start returning a HTTP 429 Too Many Requests error, and a Retry-After HTTP header containing the number of seconds until you can retry.

For example, if your app were rate limited while using conversations.info, you might see a raw HTTP response like this:

HTTP/1.1 429 Too Many Requests
Retry-After: 30

This response instructs your app to wait 30 seconds before attempting to call conversations.info with any token awarded to your application from this workspace.

Calls to other methods on behalf of this workspace are not restricted. Calls to the same method for other workspaces for this app are not restricted.

By programmatically evaluating the Retry-After header you can wait for the indicated number of seconds before retrying the same request or continuing to use that method for this workspace.

Limits when posting messages

In general, applications may post no more than one message per second per channel, whether a message is posted via chat.postMessage, an incoming webhook, or one of the many other ways to send messages in to Slack.

We allow bursts over that limit for short periods. However, if your app continues to exceed their allowance over longer periods of time, we will begin rate limiting message posting for a short duration of time.

If you go over these limits when using our Real Time Messaging API you will receive an error message as a reply. If you continue to send messages your application will be disconnected.

Continuing to send messages after being rate limited runs the risk of having your application permanently disabled.

These limits exist because Slack is primarily a communication tool for humans. Our goal is to detect applications that may be unintentionally spammy and quiet them down to avoid hindering a workspace's ability to communicate and use their archive.

Other services provide a better interface for logging, searching, aggregating and archiving on messages that occur at higher volumes. These include Papertrail (which integrates directly with Slack), Logentries (also integrates with Slack), Loggly, Splunk and LogStash.

Events API

Event deliveries to your server via the Events API are rate limited to 30,000 deliveries per workspace per hour.

When a workspace generate more than 30,000 events, you'll receive an informative event called app_rate_limited, describing the workspace and timestamp when rate limiting began.

    "token": "Jhj5dZrVaK7ZwHHjRyZWjbDl",
    "type": "app_rate_limited",
    "team_id": "T123456",
    "minute_rate_limited": 1518467820,
    "api_app_id": "A123456"

Learn more about Events API rate limiting and our tolerance for delivery failures.


Message delivery

Message delivery to your app is not rate limited over RTM. You'll receive every event the connecting token is allowed to see. You may receive more events than you can come up with, so we recommend decoupling your processing of events from the receiving of them.

Posting messages

Posting messages or other write events to the websocket is rate limited. Please limit write actions to 1 per second.

If you sustain writes beyond these limits when using our Real Time Messaging API you will receive an error message as a reply. If you continue to send messages your application will be disconnected.

The message server will disconnect any client that sends a message longer than 16 kilobytes. This includes all parts of the message, including JSON syntax, not just the message text. Clients should limit messages sent to channels to 4000 characters, which will always be under 16k bytes even with a message comprised solely of non-BMP Unicode characters at 4 bytes each. If the message is longer a client should prompt to split the message into multiple messages, create a snippet or create a post.

Obtaining websocket URLs

The rtm.start and rtm.connectWeb APIs are rate limited. Both methods yield your app the URL needed to connect to a websocket.

Limit requests to these methods to no more than 1 per minute, with some bursting behavior allowed. If you enter rate limit conditions when trying to fetch websocket URLs, you won't be able to reconnect until the window passes.

Other functionality

We reserve the right to rate limit other functionality to prevent abuse, spam, denial-of-service attacks, or other security issues. Where possible we'll return a descriptive error message, but the nature of this type of rate limiting often prevents us from providing more information.

Outgoing Webhooks

Outgoing Webhooks sent by an outgoing webhooks integration are limited to no more than one message per second, with bursts allowed over short periods to accommodate periods of high activity.

If your outgoing webhooks integration goes over this limit, outgoing webhooks for subsequent messages will not be sent until the rate of outgoing webhooks has gone below the one webhook per second limit.

This limit exists to prevent us sending your servers more events than you or we can handle. If you are reaching this rate limit, see the documentation for Outgoing Webhooks for information on how to restrict the number of messages that trigger your outgoing webhooks integration.