Docs/Api Reference/Rate Limits

Rate Limits

Unseenr enforces rate limits to ensure platform stability and fair usage.

Ingest Rate Limits

Rate limits are applied per project on the ingest endpoint (/api/{projectId}/envelope).

Default Limits by Plan

Plan Requests / Minute
Free 60
Starter 300
Pro 1,000
Business 10,000
Scale 30,000
Platform 100,000

Custom Rate Limits

Project owners can set a custom rate limit per minute in Project Settings. The custom rate limit overrides the plan default. Range: 1 to 100,000 requests per minute.

If no custom rate limit is set and the plan is not Free, no per-minute rate limit is applied (only the monthly quota is enforced).

How Rate Limiting Works

  • Window: 60 seconds (sliding)
  • Key: rl:{projectId}:{windowMinute} in Redis
  • Enforcement: Checked before quota increment (rate-limited requests do NOT count against your quota)

Rate Limit Response

When rate-limited, the endpoint returns:

HTTP 429 Too Many Requests
X-RateLimit-Remaining: 0
Retry-After: 60
{
  "error": "Rate limit exceeded"
}

Heartbeat Rate Limits

Heartbeat pings (POST https://uptime.unseenr.io/{token}) are rate-limited to 5 requests per second per token. This prevents accidental flooding from misconfigured cron jobs or monitoring scripts.

Fail-Closed Behavior

In production, if Redis is unavailable, rate limiting fails closed (blocks the request). This prevents quota bypass during infrastructure issues. In development, Redis errors are logged but requests are allowed through.

Best Practices

  • Batch events: If your SDK supports it, batch multiple events into fewer requests
  • Use sampling: Set tracesSampleRate for transactions to reduce request volume
  • Monitor headers: Check X-RateLimit-Remaining in responses to detect approaching limits
  • Handle 429s: SDKs should implement exponential backoff when receiving 429 responses
Also available in:Deutsch