Rate limiting tests should ONLY be performed on your own systems or with explicit written permission from the target organization. Unauthorized testing may violate the CFAA or local laws. Always use rate limiting test data responsibly and maintain a compliance framework.
Test Execution Plan
Time (s)RequestsExpected Status
Common Rate Limit Patterns
Token Bucket / Sliding Window
Tokens are generated at a fixed rate. Each request consumes tokens. When bucket is empty, requests are rejected or delayed. Common in modern APIs (AWS, GitHub).
Fixed Window (Hourly/Daily)
Requests allowed per fixed period (e.g., 1000/hour). Counter resets at window boundary. Can cause traffic spikes at window boundaries.
Leaky Bucket
Requests are queued and processed at constant rate. Excess requests are dropped. Similar to token bucket but different internal mechanics.
Distributed Rate Limiting
Rate limit state is distributed across multiple servers. May have slight inconsistencies between servers. Test across different IPs or instances.
Rate Limit Headers to Monitor
X-RateLimit-Limit
Total number of requests allowed in the time window
X-RateLimit-Remaining
Number of requests remaining in current window
X-RateLimit-Reset
Unix timestamp when the rate limit window resets
Retry-After
Seconds to wait before retrying (on 429 Too Many Requests)
RateLimit-Limit / RateLimit-Remaining
IETF standard headers (RFC 6585). Less common but standardized
Testing Best Practices
1. Baseline Testing
Start with slow request rates to understand the API's normal behavior before hitting limits
2. Incremental Ramp
Gradually increase request rate in steps (10, 20, 50, 100 req/s) to find breaking point
3. Burst Testing
Send sudden spike of requests to test burst tolerance before throttling kicks in
4. Monitor Reset Behavior
Test what happens at window boundaries. Some APIs spike or reset unpredictably
5. Check Throttling vs Blocking
Determine if API delays (throttles) or rejects (429) over-limit requests