BerriAI/litellm · error · Exception
Error retrieving usage data
Error message
Error retrieving usage data: {e} What it means
get_usage_data() wraps both the Prisma query_raw call and the polars conversion (pl.DataFrame(db_response, infer_schema_length=None)) in a single try/except Exception and re-raises as a new generic Exception prefixed 'Error retrieving usage data:'. The real cause — SQL failure, permissions, dropped connection, or polars schema inference problems — survives only in the appended message text, so the root cause must be read out of the string.
Solutions
- Read the text after 'Error retrieving usage data:' — it is the actual Postgres or polars error; fix that root cause first
- Verify connectivity and grants: psql "$DATABASE_URL" -c 'SELECT 1 FROM "LiteLLM_DailyUserSpend" LIMIT 1'
- Apply pending litellm DB migrations (restart the proxy so auto-migrate runs) so columns match the integration's SQL
- Bound the query: pass limit and start_time_utc/end_time_utc windows to shrink result sets
Example fix
# before df = await db.get_usage_data(start_time_utc=year_ago()) # Exception: Error retrieving usage data: statement timeout # after df = await db.get_usage_data(start_time_utc=week_ago(), end_time_utc=now_utc(), limit=50_000)
Defensive patterns
Strategy: try-catch
Try / catch
try:
df = await db.get_usage_data(limit=limit, start_time_utc=start, end_time_utc=end)
except Exception as e:
msg = str(e)
if not msg.startswith('Error retrieving usage data'):
raise
root = msg.split(':', 1)[1].strip()
logger.error('cloudzero export query failed: %s', root)
# do not blindly retry: the root cause is often schema or permissions
raise Prevention
- Run litellm DB migrations after every upgrade before exporting
- Grant the export DB user SELECT on LiteLLM_* tables and verify with a manual query
- Chunk exports by date window and set a limit to bound result size
When it happens
Trigger: Missing/renamed LiteLLM_DailyUserSpend columns after schema drift; DB user without SELECT on the spend table; connection reset mid-query; polars failing to build a DataFrame when returned rows have incompatible types even with full inference; statement timeout on very large date ranges.
Common situations: Export job pointed at the wrong database or credentials; litellm upgraded but Prisma migrations not applied so the SQL no longer matches; long unbounded date ranges pulling millions of rows; transient network issues between the export job and Postgres.
Understand the failure class
Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.
Related errors
- Database not connected. Connect a database to your proxy -…
- Error retrieving usage data
- byok_auth_unavailable
- Cannot create domain model from None record
- CloudZero configuration missing. Please set…
AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18).
Data as JSON: /api/errors/5551befe9b2e8e5a.
Report an issue: GitHub.
Appendix: source
Thrown at litellm/integrations/cloudzero/database.py:101
params: Final[list[Any]] = [
start_time_utc,
end_time_utc,
]
if limit is not None:
try:
params.append(int(limit))
except (TypeError, ValueError):
raise ValueError("limit must be an integer")
query += " LIMIT $3"
try:
db_response: Final = await client.db.query_raw(query, *params)
# Convert the response to polars DataFrame with full schema inference
# This prevents schema mismatch errors when data types vary across rows
return pl.DataFrame(db_response, infer_schema_length=None)
except Exception as e:
raise Exception(f"Error retrieving usage data: {e}")
View on GitHub (pinned to 77b7c6c40c)