Skip to main content
Temporal runs durable background workflows for the hub.

​
Talks To

​
How It Fits

Temporal runs background work that should survive process restarts, retries, and longer execution times. Apiserver starts workflow-backed behavior through Temporal when a feature should not depend on a single HTTP request completing all of the work synchronously. Typical workflow-backed behavior includes alert evaluation, scheduled jobs, notifications, and AI SRE workflows. Temporal tracks workflow state separately from Apiserver so that background work can continue independently of UI/API request handling. Workflow state is persisted in PostgreSQL. Telemetry used by a workflow is still read from ClickHouse by the application code that runs the workflow activities; Temporal itself is responsible for orchestration and durability.

​
Operational Notes

Temporal health affects background and asynchronous behavior more than the basic telemetry write path. If UI/API requests work but alerts, scheduled work, notifications, or AI workflows stall, Temporal is one of the first services to inspect. For bundled deployments, Temporal runs with PostgreSQL-backed persistence. The Temporal service layer is stateless and can be scaled horizontally as workflow load grows, while workflow history and state remain in PostgreSQL. Operators should consider Temporal and PostgreSQL together when evaluating workflow availability, because Temporal can only make progress while its persistence backend is healthy. For component-level operational guidance, see the Temporal pages in Operations.