Workflow Monitoring Sources for Durable Execution

Last verified on Nov 8, 2026.

Durable execution tools run your work for you. A workflow starts, an activity fails, the engine retries and a run that began on Monday finishes on Thursday. That is the point of them, and it is also why monitoring them is awkward. The failures are not requests that return a 500. They are runs that get slower, retry or never finish.

What the sources record

Sazabi does not read the engine's own state. It receives telemetry from the process that executes your code.

• Temporal. You add the OpenTelemetry SDK to each worker and initialize it before the worker accepts tasks. Workers send logs and telemetry, and Temporal's official OpenTelemetry tracing interceptor adds workflow and activity traces. See the Temporal integration.
• Inngest. Inngest does not emit OpenTelemetry on its own, so you instrument the application that serves your functions. That sends logs and traces for function executions. See the Inngest integration.
• Trigger.dev. You add an OTLP log exporter in trigger.config.ts. This source sends task logs only, without traces. See the Trigger.dev integration.

One caveat applies to Trigger.dev. It reserves the OTEL_* environment variables for its own internal telemetry, so don't use them for this source. Set telemetry.logExporters in the config file, not telemetry.exporters.

How teams use them together

Teams rarely run all three, but the pattern is the same. Keep the log line, the trace and the run identity linked. A retry is only readable if every attempt carries the same workflow or run ID and its attempt number. With that, a search for one run returns its whole history in order: the first failure, each retry, the final outcome.

Pair the engine's dashboard with Sazabi rather than replacing it. The dashboard knows scheduled state. Sazabi holds what the code printed while it ran.

Example: a run that keeps retrying

Say an activity that charges a card fails and retries. If your code logs structured fields, each attempt leaves a line like this example:

{
  "level": "error",
  "msg": "charge failed",
  "workflowId": "order-8841",
  "attempt": 4,
  "error": "gateway timeout after 30s"
}

Search for order-8841 and sort by time. Four attempts with the same timeout tells you the gateway is the problem. Four different errors tells you the activity itself is unstable. With Temporal's interceptor, the same search by trace ID gives you the activity span, so you can see how long each attempt waited.

If you only have the logs, put the workflow ID and attempt number into every line. It costs nothing and makes this search possible.

What to watch for across them

• Stuck runs. The signal is the absence of a completion line. Log a start line and an end line with the run ID, then query for starts without ends past the time they should have taken. This is a query you run on any stack.
• Retry storms. Count attempts per run. A rising count on one activity after a deploy usually points at that deploy.
• Idempotency. Retries run your code again. Log the idempotency key so a duplicate side effect can be traced.
• Worker health. If a worker pool stops, nothing logs, and silence is hard to see. Alert on a worker service with no lines for a period you choose.
• Payload size. Don't log full workflow inputs. Log IDs.
• Initialization order. Initialize the SDK before the worker starts, or the first runs are missing.

Detections and your own queries

None of the detections Sazabi runs today is tied to durable execution sources, so the stuck-run and retry queries above are yours to write.

For the protocol these sources use, read OpenTelemetry with Sazabi, and for the Collector that can sit in front of workers, see the Collector source.