Monitor Temporal workers and workflows with Sazabi

Last verified on Nov 8, 2026.

Temporal keeps the history of a workflow so that a crashed worker can pick up where it left off. That history tells you what the workflow decided. It does not tell you what the worker process printed while it decided, or how long an activity spent waiting on a database. That evidence lives in the workers, and workers are the part you run yourself.

Sazabi, the AI-native observability and security platform, takes worker logs and traces over OpenTelemetry. The Sazabi agent can also run the Temporal CLI against your Temporal Cloud namespace, so one thread can hold both views.

What each source sends

Worker telemetry. The Sazabi docs for this source add the OpenTelemetry SDK to each worker process and initialize it before the worker accepts tasks. Two environment variables point it at Sazabi: OTEL_EXPORTER_OTLP_ENDPOINT set to your intake URL and OTEL_EXPORTER_OTLP_PROTOCOL set to http/protobuf. Logs and traces are stored. Worker metrics are not.

The split between SDK and interceptor matters. The SDK sends worker logs and general telemetry. Workflow and activity spans come from Temporal's official OpenTelemetry tracing interceptor, which you register in the worker configuration. Temporal's TypeScript guide names the package opentelemetry-interceptors for tracing Workflows and Activities. Without it, traces arrive but contain no Temporal span data.

The Temporal CLI in the sandbox. With TEMPORAL_ADDRESS (for example <namespace>.<accountId>.tmprl.cloud:7233) and TEMPORAL_API_KEY stored, the agent can run temporal against your Cloud namespace during an investigation.

Where metrics fit

Temporal SDKs emit metrics from the Client or the Worker, configured through telemetry options on Runtime.install. Options include a Prometheus bind address and a URL for an OpenTelemetry collector. Those metrics are tagged with namespace and task_queue. Sazabi's docs say metric names such as temporal_workflow_task_execution_latency stay outside this source, so keep that path pointed at the tool you already use for it.

Questions it answers

• What did the worker log between a workflow task starting and failing?
• Which activity spans ran long, and what was the downstream service doing?
• Did a deploy of the workers change error output on one task queue?
• Is a workflow stuck because a worker is gone, or because an activity keeps failing?
• Are my workers sending anything at all after the last restart?

A worked example: traces with no workflow spans

You wire up the OpenTelemetry SDK on a worker for a checkout-queue task queue, restart it and run a workflow. The Intake page shows logs and traces from the Temporal source. But when you look for the activity that charges a card, the spans are missing.

That is the exact case Sazabi's troubleshooting section describes: workflow and activity spans require the tracing interceptor, and the base SDK does not produce them. Ask the agent to confirm it before you edit anything:

Show worker logs and traces from the Temporal source for the last 15 minutes.
Are there any workflow or activity spans, or only SDK-level traces?

If there are only SDK-level traces, add the interceptor to the worker configuration and redeploy. Then run one workflow again. The check is cheap because the same thread can pull the worker logs next to the traces.

Once the spans exist, a follow-up becomes useful: ask which activity span on checkout-queue ran longest, then ask for the logs of the service it called in the same window. If you tag runs with a Search Attribute, created with temporal operator search-attribute create, that attribute is a natural thing to name when you ask the agent about one customer's workflows.

How it fits with other integrations

Temporal is part of the durable execution category, along with Inngest and DBOS Cloud. The transport is plain OTLP, explained on the OpenTelemetry integration page. Workers often run on AWS or in Kubernetes, and both can feed the same project. See pricing for how volume counts.