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
tracesSampleRatefor transactions to reduce request volume - Monitor headers: Check
X-RateLimit-Remainingin responses to detect approaching limits - Handle 429s: SDKs should implement exponential backoff when receiving 429 responses