Discord webhooks are simple, but they are still rate-limited. If your integration posts too quickly, Discord returns a 429 response with a retry_after value.
This guide explains how to handle webhook limits safely.
What causes webhook 429 errors?
Common causes:
- Sending too many alerts at once
- Posting logs line by line
- Bulk importing messages
- Multiple workers using the same webhook
- Retrying immediately after a failure
Always respect retry_after
When Discord returns 429, your code should wait for the retry_after duration before sending again.
Bad retry logic can turn a small burst into a long outage.
Use a queue
For production alerts or bot logs, put webhook sends into a queue. A queue lets you:
- Limit concurrency
- Smooth bursts
- Retry safely
- Drop low-priority messages when needed
- Avoid blocking the main bot process
Separate important webhooks
Do not send every type of message through one webhook. Separate:
- Critical alerts
- Moderation logs
- Debug logs
- Public announcements
- Internal deployment messages
This makes rate limits easier to reason about.
Hosting matters
A stable host helps because your webhook queue keeps running. If a free host sleeps while queued messages exist, notifications can arrive late or disappear.
For bots that handle moderation, tickets, or server alerts, 24/7 hosting is worth it.