checkId: check.servicegraph.timeouts plugin: stellaops.doctor.servicegraph severity: warn tags: [servicegraph, timeouts, configuration]

Service Timeouts

This Doctor check helps operators catch timeout values that are too tight or too loose, so failures surface promptly without stuck work tying up resources.

What It Checks

Validates HttpClient:Timeout, Database:CommandTimeout, Cache:OperationTimeout, and HealthChecks:Timeout.

The check returns warn when any of the following holds, and pass otherwise:

Setting	Warns when
`HttpClient:Timeout`	below `5s` or above `300s`
`Database:CommandTimeout`	below `5s` or above `120s`
`Cache:OperationTimeout`	above `30s`
`HealthChecks:Timeout`	greater than the HTTP timeout

Why It Matters

Timeouts define how quickly failures surface and how long stuck work ties up resources. Poor values cause either premature failures or prolonged resource exhaustion.

Common Causes

Defaults from one environment were copied into another with very different latency
Health-check timeout was set higher than the main request timeout
Cache or database timeouts were raised to hide underlying performance problems

How to Fix

Docker Compose

services:
  doctor-web:
    environment:
      HttpClient__Timeout: "100"
      Database__CommandTimeout: "30"
      Cache__OperationTimeout: "5"
      HealthChecks__Timeout: "10"

Bare Metal / systemd

Tune timeouts from measured service latencies, not from guesswork. Raise values only after understanding the slower dependency.

Kubernetes / Helm

Keep application timeouts lower than ingress, service-mesh, and job-level deadlines so failures happen in the component that owns the retry policy.

Verification

stella doctor run --check check.servicegraph.timeouts

check.servicegraph.backend — timeout misconfiguration often shows up as backend failures first
check.db.latency — high database latency can force operators to revisit timeout values