Backend timeout

Cap the time Sōzune waits for a backend response before giving up. Useful to avoid stuck connections from blocking workers, or — set to zero — to allow long-lived streams.

Label

labels:
  - "sozune.http.<svc>.backendTimeout=<seconds>"

Defaults

ValueBehaviour
omitted30 seconds
0No timeout — wait indefinitely
any positive integerTimeout in seconds

Examples

Standard API, fail fast:

labels:
  - "sozune.http.api.host=api.example.com"
  - "sozune.http.api.backendTimeout=10"

Server-Sent Events / long-lived stream:

labels:
  - "sozune.http.events.host=events.example.com"
  - "sozune.http.events.backendTimeout=0"

Behaviour

  • The timer covers the full request: connecting to the backend, sending the request, and reading the response.
  • On timeout, the client receives 504 Gateway Timeout.
  • WebSocket upgrades are handled outside of this timeout — see WebSocket.

When to set it

  • Lower than 30s for user-facing APIs where a slow backend should fail fast.
  • 0 for SSE, long-polling, file uploads/downloads of unknown size, or any use case where 30s is too aggressive.
  • Around 30s is fine as a default for typical request/response APIs.

Long-polling

If your client passes a timeout parameter expecting the server to hold the request — Matrix /_matrix/client/v3/sync?timeout=30000, CometD, custom JSON long-poll — the default 30 s cut lands right when the response is about to come back. Raise backendTimeout past the longest poll, or set it to 0. See Long-polling for the full pattern.