> ## Documentation Index
> Fetch the complete documentation index at: https://metoro.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Temporal Matching Operations

> Operate the bundled Temporal Matching service in Metoro on-premises deployments

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.