Skip to main content
Temporal Worker is Temporal’s internal worker service. It runs Temporal system background work and maintenance tasks for the Temporal cluster itself. This service is separate from Metoro application workflow and activity workers. Metoro workflow behavior still depends on the application services that run workflow code, plus the Temporal services that coordinate that work.

​
Resource Profile

Temporal Worker is a stateless service layer. Durable workflow state, visibility state, and task state are persisted through PostgreSQL rather than 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 Worker-specific pressure.

​
Restarts And Availability

Temporal Worker pods can be killed, restarted, or recreated at any time without losing durable workflow state. If Worker pods restart, Temporal internal maintenance work may briefly pause and then resume after pods become ready. Workflow state remains durable in PostgreSQL during the restart.

​
Before Tuning Worker

If Temporal internal maintenance or background workflow behavior appears delayed, check these signals before changing Worker resources:
  • PostgreSQL persistence health, latency, connection pressure, and restarts.
  • Worker pod readiness, restarts, CPU throttling, memory pressure, and scheduling events.
  • Temporal workflow failures and latency in the Metoro Hub - Temporal dashboard.
  • Frontend, History, and Matching health.
  • Application service logs for the workflows or activities that appear stalled.
Tune Worker only after the signal clearly points to the Temporal Worker service rather than PostgreSQL, other Temporal components, or application workflow code.