Timeouts
Timeouts protect your application from slow networks, heavy queries, and upstream delays. Set explicit limits and design background jobs so one slow request cannot block the entire workflow.
Set timeout policies intentionally
Use explicit client timeouts
Set a timeout in your HTTP client instead of waiting indefinitely. Choose a value that matches your user experience, worker limits, and job schedule.
Retry with backoff and jitter
If a timeout is likely transient, retry after a short delay and increase the delay on each attempt. Add jitter when many workers can retry at once.
Protect user-facing routes
For long-running imports, monitoring, or enrichment workflows, hand work to a queue and return a job state instead of keeping the user waiting on a single request.
Diagnose slow requests
Track response time by endpoint
Log response time by endpoint and parameter set. Slow requests often point to expensive searches, broad filters, high page numbers, or upstream load.
Avoid duplicate work after timeouts
When retrying after a timeout, make sure your workflow can safely repeat the operation or detect that the previous attempt already completed.
Tune heavy queries first
If one query pattern times out often, narrow filters, lower page size, split the job, or cache intermediate IDs before increasing timeout limits.