Ratelimit analytics you can trust: analytics flag, pending promise, dashboard

# @upstash/ratelimit analytics you can trust

## Setup

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "10 s"),
  analytics: true,
  prefix: "@upstash/ratelimit",
});

The prefix namespaces the analytics keys. Use one prefix per
limiter so dashboards do not mix unrelated limits.

## Keep the writes alive

Analytics writes happen after limit() returns. On serverless:

const { pending } = await ratelimit.limit(id);
context.waitUntil(pending);

Without this, the dashboard undercounts. This is the number one
cause of analytics that do not match access logs.

## Read the dashboard

The Ratelimit dashboard in the console shows per-identifier
request and block counts, plus denied-request breakdowns by
country, IP, user agent, and identifier when protection is on.
Use it to:

- Find your heaviest identifiers before raising limits.
- Confirm deny-list blocks are hitting the right targets.
- Spot identifiers that are always at the ceiling: candidates
  for higher tiers or dedicated limits.

## Cost

Analytics adds one command per limit() call. Include it in your
per-request command math.

## Verify

Generate known traffic (e.g. 100 requests from a test identifier),
then check the dashboard shows roughly 100 with the right
allow/block split. If it is far off, pending is being dropped.