Monitor Inngest functions with Sazabi

Last verified on Nov 8, 2026.

An Inngest function runs in pieces. An event arrives, a step runs, the function sleeps, another step runs. When a run goes wrong, the question is rarely about Inngest itself. It is about what your code was doing inside the step, and what the services it called were doing at the same moment.

Sazabi, the AI-native observability and security platform, covers both halves. Your function host sends logs and traces through OpenTelemetry. The Sazabi agent can also run the Inngest CLI in its sandbox to look at runs and events on the Inngest side.

What Sazabi reads from Inngest

The two methods are configured separately, and connecting one does not turn on the other.

Logs and traces from the serve endpoint. The Sazabi docs for this source are blunt: Inngest does not emit OpenTelemetry on its own, so you instrument the application that hosts your functions. Set OTEL_EXPORTER_OTLP_ENDPOINT to your intake URL and OTEL_EXPORTER_OTLP_PROTOCOL to http/protobuf before the process starts. The prerequisite is a self-hosted serve endpoint, a Next.js, Express or Bun handler for example. Functions that exist only in Inngest Cloud have no host runtime to instrument. Sazabi stores the logs and traces. It does not store metrics sent to this endpoint.

That is different from Inngest's own tracing. Its extendedTracesMiddleware exports spans from your functions to Inngest Traces, and @inngest/otel sets up a Node.js provider with common instrumentation. Those features feed Inngest's dashboard. The Sazabi source is about getting the same host process's telemetry beside everything else you run.

The Inngest CLI in the sandbox. With INNGEST_API_KEY stored, and optionally INNGEST_EVENT_KEY, the agent can inspect Inngest Cloud runs, functions, deployments and events during a thread.

Questions it answers

• What did the host process log while this step was failing?
• Did the database or API a step called log an error at the same time?
• Which function runs started after the last deployment, and did they behave differently?
• What payload did the event that triggered this run carry?
• Are the traces from a slow function long because of one downstream call?

A worked example: a run that failed on one event

Inngest's event format requires name and data, and adds an optional id that prevents duplicate events and a ts timestamp in milliseconds. A support ticket says an invoice was marked paid but the customer never got a receipt. You have the event ID from the sender:

{
  "name": "billing/invoice.paid",
  "id": "evt-8841-receipt",
  "ts": 1794268800000,
  "data": {
    "customerId": "cus_example_1",
    "invoiceId": "in_example_9",
    "amount": 4900
  }
}

Ask the Sazabi agent in a thread:

Using the Inngest CLI, find the run triggered by event evt-8841-receipt. Then
show the logs from my Inngest host service in the minute around that run.

The CLI answers the Inngest-side question: did a run start, which function, and where did it stop. The logs answer the code-side question. If the host logged a 503 from the email provider's client right then, the function did what it was told and a dependency failed. If the host logged nothing, the request may never have reached your serve endpoint, which points at the deployment or the URL Inngest calls. Both answers sit in one thread, so you do not switch tools halfway through.

How it fits with other integrations

Inngest belongs to the durable execution category, next to Temporal and Trigger.dev. The wire format underneath is covered on the OpenTelemetry page. The host app often runs on a platform such as Vercel, whose logs can land in the same project. Pricing explains how volume counts, and the integrations index lists everything else.