See who is hitting limits, not just that limits were hit.
The dashboard breaks evaluations down by identifier: allowed, denied, and remaining per namespace. Find the client that is hammering you without adding your own counters.
See who is hitting limits, not just that limits were hit.
live · schematicSignal
Breakdownidentifier
Metricsallow·deny
Documentation
A rate limiter that only says "denied" is a black box. You need to know which identifier is hammering you, whether the denial was a rule or a quota, and how much headroom your real users actually have. That is what the analytics surface is for.
What you get
The dashboard breaks evaluations down per identifier and namespace:
Allowed and denied counts per identifier.
Remaining capacity per namespace.
The rules, quotas, and blocklist entries that produced each outcome.
Find the client that is burning through your budget without adding your own counters, logging identifiers, or building a metrics pipeline.
The API
Analytics are also available over the API for tooling:
The endpoint requires the read_stats scope — hand that key to your monitoring, keep it out of your hot path.
What analytics are not
Not a request log. We never store payloads, and analytics aggregate counters — they are not an audit trail of individual requests.
Not real-time streaming. Analytics answer "what happened in this window," not "what is happening this millisecond." For live state, use check() or GET /v1/ratelimit/status/:namespace.
Privacy posture
Identifiers in analytics are the ones you chose to send. If your identifier is a user ID, the breakdown is per user ID; if it is a client IP, per IP. Brume adds nothing to what you provide and retains nothing beyond the counter windows.