Monitor Trigger.dev task logs with Sazabi

Last verified on Nov 8, 2026.

A background task has no screen. When it fails at 3 a.m., the only evidence is its run log: what it printed, which call it made, when it retried. Trigger.dev keeps that log for you. You still need it next to your API and database logs, because the cause is often in a different service.

Sazabi, the AI-native observability and security platform, takes Trigger.dev task logs as a manual log source. The project's own OTLP exporter does the sending, so there is nothing to deploy beside the project.

What Sazabi reads from Trigger.dev

One method, one direction: Trigger.dev pushes task logs to your Sazabi intake URL. The source carries logs only.

The Sazabi docs for this source put an OTLPLogExporter from @opentelemetry/exporter-logs-otlp-http into telemetry.logExporters in trigger.config.ts. The exporter URL is the intake host with /v1/logs on the end. The package must be installed where trigger.config.ts lives. Trace exporters, metrics exporters, alert webhooks and management API polling are left out on purpose.

The setting name matters. Trigger.dev's config reference has three arrays: logExporters, exporters (for traces) and metricExporters. Sazabi's troubleshooting section lists the wrong array as a cause of missing logs. It also says exporters cannot be set with OTEL_* environment variables, because they would conflict with Trigger.dev's own telemetry. Sazabi's page repeats the warning. Use constructor arguments.

What counts as a log comes from Trigger.dev's logging page. The run log consists of logs, traces and spans. Plain console.log() and console.error() calls show up, as do logs from packages your task imports. Trigger.dev recommends its logger object, which writes structured logs with debug, log, info, warn and error methods. Instrumentations that you add in the config, such as the HTTP one, log calls automatically.

Questions it answers

• What did a failing task log before it threw?
• Which logger.error messages appeared after the last deploy?
• Did a task retry, and what did each attempt print?
• Which tasks log the most lines, and is that noise?
• What was the API doing when a task's HTTP call failed?
• Do the same errors show up in the task and in the service it called?

A worked example: a retry loop that hides its cause

A nightly sync task is marked as failed after three attempts. The Trigger.dev dashboard shows the run, but the real cause is on the other side of an HTTP call. The task logs through logger, using the methods from Trigger.dev's docs:

import { logger, task } from '@trigger.dev/sdk'

export const syncCustomers = task({
  id: 'sync-customers',
  run: async (payload: { batch: number }) => {
    logger.info('Sync started', { batch: payload.batch })
    const res = await fetch('https://api.example.com/customers/export')
    if (!res.ok) {
      logger.error('Export call failed', { status: res.status })
      throw new Error('export failed')
    }
  },
})

Once the exporter is in place, those lines reach Sazabi. In a thread, ask the Sazabi agent:

Show the "Export call failed" logs from the sync-customers task over the last
three nights, and the logs from my API service in the same minutes.

If the API logged a timeout or a 503 at those times, the task is only the messenger. Fix the API, then check that a retry succeeds. If the API logged nothing, the request never arrived, and the cause is networking or the URL. The question that decides it is simply whether the other side saw the call. Since both logs are in Sazabi, one query answers it.

Keep the scope narrow

This source is logs only. If you also use Trigger.dev's metrics or traces elsewhere, keep those exporters pointed at their own destinations. Logs from console and logger both flow, so decide which one your team trusts and keep messages short.

How it fits with other integrations

Trigger.dev belongs to the durable execution category. If your tasks start work in sandboxes such as Daytona or E2B, or call services hosted on AWS, those logs can sit beside the task logs in one project. The log format is covered on the OpenTelemetry integration page, and pricing explains how volume counts.