[Bug]: Usage Dashboard: Two Issues with Spend Reporting and Failed Request Attribution

[HarpreetBaathTR]

What happened?

We've identified two separate bugs in the LiteLLM usage dashboard that cause incorrect data display:

1. Frontend Pagination Bug: Total spend significantly underreported when data spans multiple pages
2. Backend Provider Attribution Bug: Failed requests show as 0 for all providers despite actual failures occurring

🔍 Bug Details

Bug 1: Frontend Pagination Aggregation Issue

Problem: The usage dashboard only displays totals from the first page of API results instead of aggregating across all pages.

API Calls Made:

/user/daily/activity?page=1  → Returns metadata with totals
/user/daily/activity?page=2  → Returns metadata with totals  
/user/daily/activity?page=3  → Returns metadata with totals
/user/daily/activity?page=4  → Returns metadata with totals

Expected: Dashboard should sum all metadata totals across pages
Actual: Dashboard only shows totals from page 1

Affected Metrics:

• Total spend
• Total API requests
• Successful/failed requests
• Token usage
• Cache statistics

Bug 2: Backend Provider Attribution Issue

Problem: "Spend by Provider" section shows failed_requests: 0 for all providers despite failed requests being tracked in overall metadata.

API Response Structure:

{
  "metadata": {
    "total_failed_requests": 162  // ✅ Correct count
  },
  "results": [
    {
      "breakdown": {
        "providers": {
          "anthropic": {
            "metrics": {
              "failed_requests": 0  // ❌ Always 0
            }
          },
          "vertex_ai": {
            "metrics": {
              "failed_requests": 0  // ❌ Always 0  
            }
          }
        }
      }
    }
  ]
}

Frontend Issue Location

• File: ui/litellm-dashboard/src/components/new_usage.tsx
• Root Cause: Pagination logic correctly fetches all pages but only retains metadata from first API response
• Impact: Affects all paginated usage reports (>1000 records)

Relevant log output

Are you a ML Ops Team?

Yes

What LiteLLM version are you on ?

1.72.2-stable

Twitter / LinkedIn details

No response

[krrishdholakia]

"metadata": {
"total_failed_requests": 162 // ✅ Correct count
},

what does a row in the daily user activity table for a failed request look like? @HarpreetBaathTR

[krrishdholakia]

cc: @NANDINI-star can you look at the UI issue outlined?

[HarpreetBaathTR]

Hi @krrishdholakia ,

I will send the details for failed request in some time, but here are some more details based on my observations.

I think there might be an issue with how custom_llm_provider attribution is handled for failed requests in the daily spend tracking. Here's what I've observed:

Failed requests appear to be attributed to "unknown" provider instead of their actual provider (like vertex_ai), causing incorrect spend aggregation in the UI.

• Model-level tracking works correctly - failed requests show up under the right models (e.g., gemini-1.5-pro-preview-0827)
• Provider-level tracking seems broken - failed requests don't get attributed to the correct provider
• This causes the total spend calculation to be incorrect since failed requests aren't grouped with their provider's successful requests

I think the issue might be in litellm/proxy/hooks/proxy_track_cost_callback.py in the async_post_call_failure_hook method around line 45-75. When a request fails, the method calls:

await proxy_logging_obj.db_spend_update_writer.update_database(
    token=user_api_key_dict.api_key,
    response_cost=0.0,
    user_id=user_api_key_dict.user_id,
    end_user_id=user_api_key_dict.end_user_id,
    team_id=user_api_key_dict.team_id,
    kwargs=request_data,  # This might be the issue
    completion_response=original_exception,
    start_time=datetime.now(),
    end_time=datetime.now(),
    org_id=user_api_key_dict.org_id,
)

The request_data being passed as kwargs might not contain the custom_llm_provider field that gets set during LiteLLM's routing process. I think this is determined after the routing logic completes, but during failures, it might not be set yet.

Later in litellm/proxy/spend_tracking/spend_tracking_utils.py around line 200+, when creating the spend log payload:

custom_llm_provider=kwargs.get("custom_llm_provider", ""),

If custom_llm_provider is missing from kwargs, it defaults to empty string, which might explain why failed requests show up under "unknown" provider.

Response for
/user/daily/activity?start_date=2025-06-20T04%3A00%3A00.000Z&end_date=2025-06-21T04%3A00%3A00.000Z&page_size=1000&page=1

Thanks!

[krrishdholakia]

Thanks for investigating further @HarpreetBaathTR , i'll look into this and try and have a fix out by tomorrow EOD.

Does that timeline work for you?

[NANDINI-star]

cc: @NANDINI-star can you look at the UI issue outlined?

@krrishdholakia Here's the FE fix: #12033