LLM Observability

connecting…

Live / current load

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.

Requests in flight right now
β€”
litellm_in_flight_requests

p50 total latency

β€”

p95 total latency

β€”

Token throughput

β€”

Request rate

β€”

Total latency distribution

Requests per latency bucket

Latency by model

Percentiles since the last container restart, per model

Historical usage

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.

Range Custom to

Requests in range

β€”

Tokens in range

β€”
Server-reported total

Busiest day

β€”

Days with token data

β€”
Some days report requests but zero tokens

API requests per day

api_requests, daily buckets

Total tokens per day

total_tokens, daily buckets β€” plotted separately from requests, on its own scale

Per-team breakdown

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.

Tokens by team

Input and output tokens since the last container restart

Budget utilisation

Utilisation needs both a live remaining-budget gauge and a real Team object. Anything else is reported honestly rather than guessed.

Team detail

Models and key aliases seen per team in the current metrics scrape

Most recent raw requests

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.

Show recent request log