Read from LiteLLM's Prometheus endpoint. These are counters that reset to zero whenever the LiteLLM container restarts, so this panel describes current state only β never a trend. Historical figures are further down.
p50 total latency
p95 total latency
Token throughput
Request rate
Requests per latency bucket
Percentiles since the last container restart, per model
Daily buckets from /global/activity, which is backed by PostgreSQL and is
the authoritative source for history. Already bucketed server-side β nothing is
re-aggregated here.
Requests in range
Tokens in range
Busiest day
Days with token data
api_requests, daily buckets
total_tokens, daily buckets β plotted separately from requests, on its own scale
Teams are discovered from the team label on the Prometheus metrics, not from
/team/list. Token and request counts therefore cover the period since the last
LiteLLM container restart. /team/list and /team/info are consulted only to
enrich a row with a configured max_budget.
Input and output tokens since the last container restart
Utilisation needs both a live remaining-budget gauge and a real Team object. Anything else is reported honestly rather than guessed.
Models and key aliases seen per team in the current metrics scrape
From /spend/logs called with no date parameters. Passing both
start_date and end_date silently switches that endpoint to a different
aggregate shape, so this view never sends them and the backend validates the
response shape before any row is rendered.