Rate Limiting and 429 Errors

Introduction

Rate limiting occurs when you send too many requests too quickly, causing platforms or services to temporarily reject requests with 429 "Too Many Requests" errors. This guide explains rate limiting, how ServerTrack handles it, and best practices for avoiding rate limit issues.

What is Rate Limiting?

Rate limiting is a mechanism that restricts the number of requests that can be made within a specific time period. Platforms implement rate limits to:

• Prevent API abuse
• Ensure fair resource usage
• Maintain system stability
• Protect against overload

When rate limits are exceeded, platforms return HTTP 429 "Too Many Requests" status code.

Platform Rate Limits

Facebook Conversions API

• Standard Limits: ~50,000 events per hour per pixel
• Burst Limits: Up to 10,000 events per minute
• Best Practice: Spread events evenly over time

TikTok ePIG

• Standard Limits: ~50,000 events per hour per pixel
• Burst Limits: Varies by account level
• Best Practice: Avoid sending large batches at once

Google Analytics 4

• Standard Limits: ~1 million events per day per property
• Per-Request Limits: ~200 events per request
• Best Practice: Batch events when possible

ServerTrack Rate Limits

• Plan-Based Limits: Your plan determines monthly event limits
• Grace Period: Up to 1,000 events over limit allowed
• Hard Limit: Events blocked when limit + 1,000 exceeded

Understanding 429 Errors

HTTP 429 "Too Many Requests" errors indicate:

• Too many requests sent in a short time period
• Rate limit threshold exceeded
• Platform temporarily rejecting requests
• Need to wait before sending more requests

429 errors are temporary - they typically resolve after waiting a short period (seconds to minutes).

How ServerTrack Handles Rate Limiting

Automatic Retry with Exponential Backoff

When ServerTrack receives a 429 error:

1. Event is marked as "failed" initially
2. Event is automatically queued for retry
3. Retry happens with exponential backoff (delays increase: 1s, 2s, 4s, 8s, etc.)
4. Up to 10 retry attempts
5. If all retries fail, event is marked as "max_retries_failed"

Retry Logic

• Automatic: No action required from you
• Intelligent: Exponential backoff prevents overwhelming platforms
• Persistent: Retries continue for up to 3 days
• Platform-Aware: Each platform retried independently

Identifying Rate Limiting Issues

Check Event Logs for 429 Errors

1. Go to Event Logs in your ServerTrack dashboard
2. Filter by "Failed" status
3. Look for events with 429 errors in response messages
4. Check error frequency and timing patterns

Common Error Messages

• "429 Too Many Requests"
• "Rate limit exceeded"
• "Too many requests, please retry later"
• "Request rate limit exceeded"

Identify Patterns

• Burst Traffic: Many events in a short time period
• Scheduled Campaigns: Events sent at specific times (e.g., email campaigns)
• High Traffic Periods: Events during peak website traffic

Preventing Rate Limiting

1. Spread Events Over Time

• Avoid sending large batches of events at once
• Implement throttling on your side if needed
• Use event queuing to smooth out traffic

2. Monitor Event Volume

• Check your event volume in ServerTrack analytics
• Identify peak traffic periods
• Plan for expected traffic spikes

3. Upgrade Your Plan if Needed

• If consistently hitting plan limits, consider upgrading
• Higher plans have higher event limits
• Monitor usage regularly

4. Optimize Event Tracking

• Only track necessary events
• Avoid duplicate events
• Use event batching when possible

Handling Burst Traffic

Burst traffic (sudden spikes in events) can trigger rate limits:

Scheduled Marketing Campaigns

• Email campaigns can trigger many events at once
• Consider staggering campaign sends
• Monitor event volume during campaigns

Viral Content or Sales

• Sudden traffic spikes from viral content
• Flash sales or limited-time offers
• ServerTrack handles these automatically with retries

How ServerTrack Handles Bursts

• Events are queued for processing
• Automatic retry with backoff for rate-limited events
• Most events eventually succeed after rate limits reset

Optimizing Event Sending Frequency

Batch Events When Possible

Instead of sending individual events:

• Batch multiple events into single requests (where supported)
• Reduce number of HTTP requests
• More efficient and less likely to hit rate limits

Client-Side Throttling

If needed, implement throttling on your website:

• Debounce rapid events (e.g., scroll events)
• Queue events and send in batches
• Limit events per session

When to Contact Support

Contact ServerTrack support if:

• Rate limiting persists for more than a few hours
• 429 errors affect all platforms simultaneously
• Event volume is consistently very high (may need plan upgrade)
• Rate limiting prevents critical events from being sent

Monitoring Rate Limits

Check Analytics Dashboard

• Monitor event volume trends
• Identify peak traffic periods
• Watch for sudden spikes

Check Event Logs Regularly

• Review failed events for 429 errors
• Check retry success rates
• Monitor for patterns in failures

Best Practices

• Plan Ahead: Monitor event volume and plan for spikes
• Trust Retries: ServerTrack automatically retries rate-limited events
• Monitor Regularly: Check event logs and analytics
• Upgrade When Needed: Consider upgrading plan if consistently hitting limits
• Optimize Tracking: Only track necessary events

Summary

Rate limiting and 429 errors:

• Occur when too many requests are sent too quickly
• Are temporary and typically resolve automatically
• Are automatically handled by ServerTrack with retries
• Can be prevented by spreading events over time

Key points:

• ServerTrack automatically retries rate-limited events
• Retries use exponential backoff to avoid overwhelming platforms
• Most rate limiting resolves automatically within minutes
• Monitor event volume and plan for traffic spikes
• Consider upgrading plan if consistently hitting limits

Rate limiting is normal during high traffic periods. ServerTrack's automatic retry system ensures events are eventually delivered successfully.

For more information, see our High Event Failure Rate Diagnostics guide.