home / skills / jeremylongshore / claude-code-plugins-plus-skills / posthog-rate-limits
This skill implements PostHog rate limiting with exponential backoff and idempotency, enabling reliable retries and preventing duplicates.
npx playbooks add skill jeremylongshore/claude-code-plugins-plus-skills --skill posthog-rate-limitsReview the files below or copy the command above to add this skill to your agents.
---
name: posthog-rate-limits
description: |
Implement PostHog rate limiting, backoff, and idempotency patterns.
Use when handling rate limit errors, implementing retry logic,
or optimizing API request throughput for PostHog.
Trigger with phrases like "posthog rate limit", "posthog throttling",
"posthog 429", "posthog retry", "posthog backoff".
allowed-tools: Read, Write, Edit
version: 1.0.0
license: MIT
author: Jeremy Longshore <[email protected]>
---
# PostHog Rate Limits
## Overview
Handle PostHog rate limits gracefully with exponential backoff and idempotency.
## Prerequisites
- PostHog SDK installed
- Understanding of async/await patterns
- Access to rate limit headers
## Instructions
### Step 1: Understand Rate Limit Tiers
| Tier | Requests/min | Requests/day | Burst |
|------|-------------|--------------|-------|
| Free | 60 | 1,000 | 10 |
| Pro | 300 | 10,000 | 50 |
| Enterprise | 1,000 | 100,000 | 200 |
### Step 2: Implement Exponential Backoff with Jitter
```typescript
async function withExponentialBackoff<T>(
operation: () => Promise<T>,
config = { maxRetries: 5, baseDelayMs: 1000, maxDelayMs: 32000, jitterMs: 500 }
): Promise<T> {
for (let attempt = 0; attempt <= config.maxRetries; attempt++) {
try {
return await operation();
} catch (error: any) {
if (attempt === config.maxRetries) throw error;
const status = error.status || error.response?.status;
if (status !== 429 && (status < 500 || status >= 600)) throw error;
// Exponential delay with jitter to prevent thundering herd
const exponentialDelay = config.baseDelayMs * Math.pow(2, attempt);
const jitter = Math.random() * config.jitterMs;
const delay = Math.min(exponentialDelay + jitter, config.maxDelayMs);
console.log(`Rate limited. Retrying in ${delay.toFixed(0)}ms...`);
await new Promise(r => setTimeout(r, delay));
}
}
throw new Error('Unreachable');
}
```
### Step 3: Add Idempotency Keys
```typescript
import { v4 as uuidv4 } from 'uuid';
import crypto from 'crypto';
// Generate deterministic key from operation params (for safe retries)
function generateIdempotencyKey(operation: string, params: Record<string, any>): string {
const data = JSON.stringify({ operation, params });
return crypto.createHash('sha256').update(data).digest('hex');
}
async function idempotentRequest<T>(
client: PostHogClient,
params: Record<string, any>,
idempotencyKey?: string // Pass existing key for retries
): Promise<T> {
// Use provided key (for retries) or generate deterministic key from params
const key = idempotencyKey || generateIdempotencyKey(params.method || 'POST', params);
return client.request({
...params,
headers: { 'Idempotency-Key': key, ...params.headers },
});
}
```
## Output
- Reliable API calls with automatic retry
- Idempotent requests preventing duplicates
- Rate limit headers properly handled
## Error Handling
| Header | Description | Action |
|--------|-------------|--------|
| X-RateLimit-Limit | Max requests | Monitor usage |
| X-RateLimit-Remaining | Remaining requests | Throttle if low |
| X-RateLimit-Reset | Reset timestamp | Wait until reset |
| Retry-After | Seconds to wait | Honor this value |
## Examples
### Queue-Based Rate Limiting
```typescript
import PQueue from 'p-queue';
const queue = new PQueue({
concurrency: 5,
interval: 1000,
intervalCap: 10,
});
async function queuedRequest<T>(operation: () => Promise<T>): Promise<T> {
return queue.add(operation);
}
```
### Monitor Rate Limit Usage
```typescript
class RateLimitMonitor {
private remaining: number = 60;
private resetAt: Date = new Date();
updateFromHeaders(headers: Headers) {
this.remaining = parseInt(headers.get('X-RateLimit-Remaining') || '60');
const resetTimestamp = headers.get('X-RateLimit-Reset');
if (resetTimestamp) {
this.resetAt = new Date(parseInt(resetTimestamp) * 1000);
}
}
shouldThrottle(): boolean {
// Only throttle if low remaining AND reset hasn't happened yet
return this.remaining < 5 && new Date() < this.resetAt;
}
getWaitTime(): number {
return Math.max(0, this.resetAt.getTime() - Date.now());
}
}
```
## Resources
- [PostHog Rate Limits](https://docs.posthog.com/rate-limits)
- [p-queue Documentation](https://github.com/sindresorhus/p-queue)
## Next Steps
For security configuration, see `posthog-security-basics`.This skill implements robust rate limiting, retry/backoff, and idempotency patterns for PostHog API clients. It provides practical code patterns for exponential backoff with jitter, idempotency keys, queue-based throttling, and monitoring rate-limit headers to avoid duplicate events and request storms. Use it to make PostHog integrations resilient under 429s and transient server errors.
The skill inspects HTTP status codes and rate-limit headers (X-RateLimit-*, Retry-After) to decide when to pause or retry requests. It retries transient failures (429 and 5xx) using exponential backoff with random jitter, honors Retry-After and reset timestamps, and attaches deterministic idempotency keys so retries do not create duplicates. It also shows queue-based throttling to shape throughput and a small monitor to track remaining quota.
Should I retry on every 4xx error?
No. Retry only on 429 (rate limit) and 5xx transient errors. Other 4xx responses are usually client errors that require code changes.
How do idempotency keys prevent duplicates?
Deterministic idempotency keys derived from operation parameters let the server identify retries of the same logical operation and avoid creating duplicate records.