Issue Station
Sign In
Tools hereToolbox

litellm - 💡(How to fix) Fix [BUG]: llm_requests_hanging Slack alert fired at 600s threshold but no >=600s request in spend logs [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#26019•Fetched 2026-04-19 15:06:15
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
SunsilkkSunsilkk
Participants
metalshankedmetalshankedSunsilkkSunsilkk
Timeline (top)
labeled ×2commented ×1

Code Example

alert timestamp: 2026-04-18T16:55:59+00:00
model: openrouter/google/gemini-3.1-flash-lite-preview

spend/logs analysis window: 2026-04-18 00:00:00 .. 2026-04-19 23:59:59
rows: 5931
max request_duration_ms: 595218
count(request_duration_ms >= 600000): 0

near alert time for alerted model:
request_id=gen-1776531355-V1fR4CWjIbcARDQHrHp4
start=2026-04-18T16:55:55.854+00:00
end=2026-04-18T16:56:07.425+00:00
duration_s=11.571
status=success
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

We received a Slack alert for hanging requests:

  • Alert type: llm_requests_hanging
  • Message: Requests are hanging - 600s+ request time
  • Request Model: openrouter/google/gemini-3.1-flash-lite-preview
  • Alert timestamp: 2026-04-18 16:55:59 UTC (2026-04-18 23:55:59 Asia/Ho_Chi_Minh)

However, spend logs do not show any request that actually exceeded 600 seconds.

What we validated

  • LiteLLM version: 1.83.9
  • litellm.request_timeout: 600
  • Queried /spend/logs/v2 over 2026-04-18 00:00:00 to 2026-04-19 23:59:59
  • Total rows analyzed: 5931
  • Rows with request_duration_ms >= 600000: 0
  • Maximum observed request_duration_ms: 595218 (still below 600s)

For the specific alerted model openrouter/google/gemini-3.1-flash-lite-preview around the alert minute:

  • all requests were success
  • durations were roughly 1s to 11.7s
  • sample overlapping request:
    • request_id: gen-1776531355-V1fR4CWjIbcARDQHrHp4
    • start: 2026-04-18T16:55:55.854+00:00
    • end: 2026-04-18T16:56:07.425+00:00
    • duration: ~11.57s

So Slack indicates 600s+ hanging, but persisted request logs do not contain any matching hanging request.

Steps to Reproduce

  1. Enable Slack alerting with llm_requests_hanging and threshold 600.
  2. Run normal traffic on model openrouter/google/gemini-3.1-flash-lite-preview.
  3. Observe Slack alert: Requests are hanging - 600s+ request time.
  4. Query /spend/logs/v2 for the same period and verify no request has request_duration_ms >= 600000.

Relevant log output

alert timestamp: 2026-04-18T16:55:59+00:00
model: openrouter/google/gemini-3.1-flash-lite-preview

spend/logs analysis window: 2026-04-18 00:00:00 .. 2026-04-19 23:59:59
rows: 5931
max request_duration_ms: 595218
count(request_duration_ms >= 600000): 0

near alert time for alerted model:
request_id=gen-1776531355-V1fR4CWjIbcARDQHrHp4
start=2026-04-18T16:55:55.854+00:00
end=2026-04-18T16:56:07.425+00:00
duration_s=11.571
status=success

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

1.83.9

Twitter / LinkedIn details

No response

extent analysis

TL;DR

The issue might be resolved by investigating the Slack alerting mechanism for llm_requests_hanging to determine why it's triggering false positives for request hang times.

Guidance

  • Review the Slack alert configuration for llm_requests_hanging to ensure it's correctly set up to detect requests exceeding 600 seconds.
  • Investigate the logic behind the alert to understand how it calculates request durations and what might cause it to report hang times that aren't reflected in the spend logs.
  • Verify that the time zones and timestamps used by the Slack alert and the spend logs are consistent to rule out any discrepancies due to time zone differences.
  • Consider temporarily adjusting the alert threshold to a lower value to see if the issue persists, which could help in isolating the problem.

Example

No specific code example is provided due to the lack of direct code references in the issue description.

Notes

The solution may involve adjusting the alerting system rather than the LiteLLM version or the request handling logic, as the logs do not show any requests exceeding the 600-second threshold.

Recommendation

Apply a workaround by adjusting the Slack alert configuration to better align with the actual request durations observed in the spend logs, as there's no clear indication that an upgrade to a different LiteLLM version would resolve the discrepancy between the alert and the logged request durations.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#logging issue#authentication issue#prompt issue#agent setup#task chaining

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - 💡(How to fix) Fix [BUG]: llm_requests_hanging Slack alert fired at 600s threshold but no >=600s request in spend logs [1 comments, 2 participants]