Skip to main content
Temporal Matching routes workflow and activity tasks between Temporal task queues and workers. It is the dispatch layer that lets workflow workers receive work and report progress.

​
Resource Profile

Matching is a stateless service layer for task queue routing. Durable workflow state remains in PostgreSQL, and work that has not completed is retained by Temporal persistence rather than by local pod storage. The bundled defaults should normally be left as they are. Manual scaling or resource tuning should be rare and should happen only with Metoro support or sustained Matching-specific pressure.

​
Restarts And Availability

Temporal Matching pods do not own durable workflow state locally. Individual pods can be killed, restarted, or recreated at any time without losing workflow state or completed telemetry. During a Matching restart, task dispatch may briefly slow while clients reconnect and Temporal rebalances work. Once ready Matching pods are available, workflow and activity task polling should continue.

​
Before Tuning Matching

If workflows are scheduled but activities or workflow tasks are delayed, check these signals before changing Matching resources:
  • Temporal task queue backlog and task latency in the Metoro Hub - Temporal dashboard.
  • Matching pod readiness, restarts, CPU throttling, memory pressure, and scheduling events.
  • Health of the application workers polling the affected task queues.
  • PostgreSQL persistence health and latency.
  • History health, because workflow state transition delays can appear as task dispatch delays.
Tune Matching only after the signal clearly points to Matching capacity rather than worker availability, persistence, or History.