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-limits

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.3 KB
---
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`.

Overview

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.

How this skill works

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.

When to use it

  • When PostHog returns 429 or you see X-RateLimit-Remaining approaching zero
  • When implementing retries for transient 5xx or network errors
  • When you must avoid duplicate events from retried requests
  • When integrating high-throughput pipelines or background workers with PostHog
  • When you need predictable API throughput and burst shaping

Best practices

  • Honor Retry-After and X-RateLimit-Reset headers before retrying or resuming heavy traffic
  • Use exponential backoff with capped max delay and jitter to prevent thundering-herd retries
  • Generate deterministic idempotency keys from operation parameters for safe retries
  • Combine a local rate-limit monitor with a queue (concurrency + intervalCap) to shape bursts
  • Log rate-limit metrics and alerts when remaining quota is low to avoid silent failures

Example use cases

  • Server-side event ingestion: queue events, attach idempotency keys, and retry on 429s
  • ETL jobs that push large batches to PostHog while honoring daily and per-minute caps
  • Realtime integrations where transient errors must be retried without duplicating events
  • Background workers that auto-throttle when X-RateLimit-Remaining is low
  • API clients that need predictable backoff behavior for SDK-driven requests

FAQ

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.