Incident Library
Applied filters Root causeDNS or network faultDomainKubernetesOrganisationUzabaseClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. Symptoms

    At Uzabase, a product team in the Speeda business uses an LLM agent to extract companies' management issues from public documents, and a client pod run as a Kubernetes Job sends the requests to the agent. The agent reviews its output many times, so a response often takes more than 15 minutes. Some share of the requests never got a response, with no clear pattern in which ones.

    Trigger

    LLM agent requests that took more than 15 minutes without packets on the TCP connection.

    Root cause
    Component
    Contributing factor
    Detection

    Client Job pods were not getting responses for some requests to the agent; the client log showed tasks that started but never finished until the 60-minute forced retry.

    Remediation
    • Turned on TCP keepalive in the Python client so packets keep the connection alive
    Lessons

    Application engineers also need to know the network and infrastructure. As AI applications with long response times become common, a silent cut of a long request can come from a network setting such as the IPVS TCP timeout.

Check your cluster for this

This case involves kube-proxy. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1