What causes "Failed to list budgets." in BerriAI/litellm?

Pull the proxy logs for the same timestamp — the original exception and traceback are recorded there

BerriAI/litellm · error · ManagementProblem

urn:litellm:error:internal-server-error

urn:litellm:error:internal-server-error

Error message

Failed to list budgets.

What it means

The catch-all for GET /management/v1/budgets: any exception that is not itself a ManagementProblem (Prisma/driver errors, serialization bugs, unexpected None) is logged server-side via verbose_proxy_logger.exception and converted into a 500 RFC 9457 problem (type urn:litellm:error:internal-server-error, detail 'Failed to list budgets.'). The client gets a stable, opaque problem; the traceback lives in the proxy logs.

Source

Thrown at litellm/proxy/management_endpoints/management_v1/budgets.py:196

                    status=503,
                    detail=CommonProxyErrors.db_not_connected_error.value,
                )
            )

        return await handle_list(
            spec=BUDGETS_LIST_SPEC,
            executor=PrismaBudgetListExecutor(prisma_client=prisma_client),
            request=request,
            caller=user_api_key_dict,
        )

    except ManagementProblem:
        raise
    except Exception as e:  # noqa: BLE001  # a driver error answers as a problem document, not the OpenAI error shape
        verbose_proxy_logger.exception(
            "litellm.proxy.management_endpoints.management_v1.budgets.list_budgets(): Exception occured - %s", e
        )
        raise ManagementProblem(
            ProblemDetail(
                type=f"{PROBLEM_TYPE_BASE}internal-server-error",
                title="Internal server error",
                status=500,
                detail="Failed to list budgets.",
            )
        )

View on GitHub (pinned to 77b7c6c40c)

Solutions

Pull the proxy logs for the same timestamp — the original exception and traceback are recorded there
Apply pending migrations (litellm --migrate) if the schema is behind the running version
Check DB health (connection count, disk, failover state) and retry once it is healthy
If it is reproducible with a specific query (e.g. a particular sort/filter), reduce the request to the minimal failing form and report it with logs

Defensive patterns

Strategy: retry

Try / catch

async def list_budgets_with_retry(client, q, attempts=3):
    for i in range(attempts):
        r = await client.get('/management/v1/budgets', params=q)
        if r.status_code == 200:
            return r.json()
        if r.status_code == 500 and 'internal-server-error' in r.text:
            await asyncio.sleep(2 ** i)   # transient DB/driver failure; back off and retry
            continue
        r.raise_for_status()
    raise RuntimeError('list budgets kept failing with 500')

Prevention

Retry only idempotent GET list calls, with capped exponential backoff
Alert with the proxy-side traceback (grep verbose_proxy_logger for the timestamp), not just the client problem
Keep migrations in lockstep with the deployed proxy version to avoid schema-drift 500s

When it happens

Trigger: Postgres restarting or hitting max_connections during the query; schema drift where the DB lacks expected budget columns (migrations not applied); a bug in a custom executor/serializer; out-of-memory or timeouts in the count/find_many calls.

Common situations: DB failover mid-request; deploying a new proxy version against an old unmigrated database; heavy pages (huge page_size) triggering driver timeouts.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/a1d94abde33282c7. Report an issue: GitHub.