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

  1. Read the text after 'Error retrieving usage data:' — it is the actual Postgres or polars error; fix that root cause first
  2. Verify connectivity and grants: psql "$DATABASE_URL" -c 'SELECT 1 FROM "LiteLLM_DailyUserSpend" LIMIT 1'
  3. Apply pending litellm DB migrations (restart the proxy so auto-migrate runs) so columns match the integration's SQL
  4. 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

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


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)