Skip to main content
Temporal History manages workflow execution state. It applies workflow state transitions, stores workflow history, manages timers, and persists durable workflow state through PostgreSQL.

​
Resource Profile

History is part of the Temporal service layer. It keeps in-memory working state while handling workflow progress, but the durable source of truth is PostgreSQL. The bundled defaults are intended to be left alone for normal Metoro Hub deployments. Manual scaling or resource tuning should be rare and should happen only with Metoro support or sustained History-specific pressure.

​
Restarts And Availability

Temporal History pods are stateless with respect to durable workflow state. Workflow histories and state are persisted in PostgreSQL. Individual History pods can be killed, restarted, or recreated at any time without losing durable workflow state. Temporal may need to rebalance ownership and reload workflow state after a pod restart, so workflow progress can briefly pause, but persisted workflows should continue once healthy pods are available.

​
Before Tuning History

If background workflows stall or workflow latency increases, check these signals before changing History resources:
  • PostgreSQL persistence health, latency, connection pressure, and restarts.
  • History pod readiness, restarts, CPU throttling, memory pressure, and scheduling events.
  • Temporal task queue backlog, workflow failures, and activity latency in the Metoro Hub - Temporal dashboard.
  • Matching health, because task dispatch problems can look like workflow progress problems.
  • ClickHouse query health for workflows that run telemetry-backed activities.
Tune History only after the signal clearly points to History capacity rather than PostgreSQL, Matching, ClickHouse, or application workflow code.