Rate Limits

Unseenr setzt Rate Limits durch, um Plattformstabilität und faire Nutzung sicherzustellen.

Ingest Rate Limits

Rate Limits werden pro Projekt auf dem Ingest-Endpoint (/api/{projectId}/envelope) angewendet.

Standard-Limits nach Plan

Eigene Rate Limits

Projekt-Owner können ein eigenes Rate Limit pro Minute in den Projekteinstellungen setzen. Das eigene Rate Limit überschreibt den Plan-Standard. Bereich: 1 bis 100.000 Anfragen pro Minute.

Wenn kein eigenes Rate Limit gesetzt ist und der Plan nicht Free ist, wird kein Pro-Minute-Rate-Limit angewendet (nur das monatliche Kontingent wird durchgesetzt).

Wie Rate Limiting funktioniert

• Fenster: 60 Sekunden (gleitend)
• Key: rl:{projectId}:{windowMinute} in Redis
• Durchsetzung: Wird vor dem Kontingent-Increment geprüft (Rate-limitierte Anfragen zählen NICHT gegen dein Kontingent)

Rate-Limit-Antwort

Bei Erreichen des Rate Limits gibt der Endpoint zurück:

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}) sind auf 5 Anfragen pro Sekunde pro Token begrenzt. Das verhindert versehentliches Flooding durch falsch konfigurierte Cronjobs oder Monitoring-Scripts.

Fail-Closed-Verhalten

In Produktion, wenn Redis nicht verfügbar ist, wird Rate Limiting fail-closed (blockiert die Anfrage). Das verhindert Kontingent-Bypass bei Infrastrukturproblemen. In der Entwicklung werden Redis-Fehler geloggt, aber Anfragen durchgelassen.

Best Practices

• Events batchen: Wenn dein SDK es unterstützt, fasse mehrere Events in weniger Anfragen zusammen
• Sampling nutzen: Setze tracesSampleRate für Transaktionen, um das Anfragevolumen zu reduzieren
• Header überwachen: Prüfe X-RateLimit-Remaining in Antworten, um nahende Limits zu erkennen
• 429er behandeln: SDKs sollten exponentielles Backoff bei 429-Antworten implementieren