Ticket Rate Limits

There is a ceiling on how fast tickets can be opened: one for each member, and two for the server as a whole. The limits exist so a raid or a misconfigured automation cannot fill a server with ticket channels faster than staff can close them. Discord itself caps a server at 500 channels and a category at 50, so a burst that goes unchecked does lasting damage rather than just making noise.

Ordinary use does not come close. The limits are set well above the busiest activity we have ever recorded on a real server.

The limits

All three apply at once. A member is stopped by the first one they reach, whether that is their own limit or the server's.

The per-member limit is counted separately in each server, so being active in one server never uses up someone's allowance in another.

The hourly server limit is the one that matters most. A per-minute cap on its own still allows hundreds of channels an hour, which is enough to hit Discord's 500-channel ceiling before anyone notices.

What members see

When a member reaches their own limit, the bot replies to them privately:

Slow down a moment

You have opened 3 tickets in the last minute, which is the most this server allows per member. You can open another in 24 seconds.

When the server as a whole is at its limit, everyone trying to open a ticket sees this instead:

Server ticket limit

10 tickets were opened here in the last minute, which is this server's limit. New tickets can be opened again in 31 seconds. Server admins can raise this limit on a paid plan.

Both messages are only visible to the member who tried, so a burst does not spam the channel. Reactions are the one exception: there is no private reply available on a reaction, so a rate-limited reaction is ignored without a message.

Nothing is lost when a limit is reached. The member can open their ticket as soon as the countdown ends.

Raising the limit

Every paid plan carries higher limits, listed in the table above. If a free server is regularly reaching the server-wide limit through genuine use, that is the point to upgrade. See Server Plans.

If the limit is being reached because of a raid rather than real demand, raising it is the wrong fix. Restrict who can open tickets instead: category permissions can require a role, and blacklisted roles are turned away before any ticket is created.

Automations are worth checking too. A support flow or an automation rule that creates a ticket on a trigger that fires often will use the server's allowance without anyone clicking anything.

Using the API

POST /v1/tickets returns 429 with the error code rate_limited when a limit is reached, and a Retry-After header giving the number of seconds until the bucket resets. Wait that long before retrying rather than retrying immediately, and pace bulk imports so they stay inside the per-hour limit. See the API reference.