Changelog

Scoring lets you attach a named quality signal to a function run, a step, or an experiment variant. It shines for AI evals: run an LLM-as-a-judge over a result and write the verdict back as a score with inngest.score({ name, value }), or defer the judge entirely so a slow model call never blocks the run that produced the output. A score is just a named number or boolean, so it tracks ordinary product signals too, from click-through and saves to conversions and error rates.

Reach for it whenever you need to judge how well code ran, not just whether it succeeded: LLM-as-a-judge evals, deterministic guardrails (length, format, refusal checks), engagement signals, and human ratings. Scores are how you turn an experiment into a winner.

• Score right at the execution layer. Scores land on the run itself, alongside the rest of the execution metadata Inngest already captures, not in a separate metrics pipeline. inngest.score() writes immediately, and step.score("id", { name, value }) records the score as a durable, memoized step.
• Defer expensive scorers. createScorer() turns an LLM-as-a-judge, or any other eval, into a deferred function. Trigger it with defer() from your run and the score is written for you, off the critical path, without blocking the result a user sees.
• Score variants from anywhere. inngest.score.experiment() credits a score to the experiment variant that produced a result, even when the signal arrives much later in a separate run: a click, a rating, or a judge's verdict.

Scoring is available now in beta in the Inngest TypeScript SDK. Install the latest with npm install inngest@latest. inngest.score() lives on the client. step.score() needs scoreMiddleware(), which, along with createScorer, is imported from inngest/experimental.

• Score a function run
• Build a deferred scorer
• inngest.score() reference

We've added Sessions to make it easier to investigate related work across your environment.

When sending events, attach a stable session key and ID with meta.sessions, then use the Sessions page to jump from a domain concept like a conversation, support ticket, or import to the runs it produced.

This is especially useful for AI agents and long-running workflows where one user action can fan out into multiple functions. Sessions show run counts, failures, recent activity, and the functions involved for each session.

Read the Sessions docs to start sending sessions with your events.

Experiments let you compare versions of a step on live production traffic, judged on the execution data only Inngest can see. Call group.experiment("your-id", { variants, select }) with the implementations you want to compare and a selection strategy, and Inngest runs exactly one variant per run, memoized as a durable step so retries and replays never switch mid-execution.

Reach for them when you're rolling out a rewrite, migrating a vendor or database, swapping an implementation, or comparing models and prompts: anywhere you want to know which version actually performed better against real traffic, not just whether it breaks.

• Judged on execution data — Variants are compared on the timing, retries, failures, and cost Inngest already records for every run. The same data that keeps your code durable tells you which version is faster, cheaper, or more effective, with no extra pipeline to wire up.
• Durable selection — One variant runs per run, memoized as a step. Change weights between deploys and in-flight runs keep the variant they already picked, so a ramp never disturbs work already underway.
• Strategies for the whole lifecycle — Ramp with experiment.weighted(), keep a user or whole organization consistent with experiment.bucket(), drive selection from a feature flag with experiment.custom() for a no-deploy kill switch, then lock the winner with experiment.fixed().
• The function stays put — Evolve an experiment by changing weights, bucketing, or the fixed winner, never by rewriting the workflow. Pin a winner and the structure stays in place for the next challenger.

Experiments are available now in the Inngest TypeScript SDK (v4). Import experiment from inngest and call group.experiment() inside any function.

See the Run experiments in production pattern for rollout patterns, and the group.experiment() reference for the full API.

Deferred Functions are a new way to launch independent background work from inside an Inngest function. Call defer("some-id", { function, data }) and the parent run keeps executing — the deferred run is fully independent, with its own retries, concurrency, step state, and typed payload.

Reach for them when work should happen because of a run, not as part of it: scoring an agent's output, sending a notification, logging a side effect, or queueing follow-up work.

• Fire-and-forget — defer(...) is synchronous and returns void. The parent doesn't block and never sees a result.
• Typed payloads — Define a Standard Schema on the deferred function and data is validated on both the caller and receiver side, then typed in the handler.
• Fully independent runs — Each call triggers its own run with its own retries, concurrency, and step state. Multiple parents can target the same deferred function.
• Works inside steps — Call defer(...) directly in a handler or from inside step.run().

Deferred Functions are available now in beta via createDefer from inngest/experimental in the TypeScript SDK. A great use case is the new deferred LLM scorer.

See the Deferred Functions reference for the full API.

We've improved Insights and added new datasources, functionality and syntax support.

New datasources include:

• Runs: Query your function runs and their associated data, such as input, output, and execution time.
• Steps/StepAttempts: Query the individual steps within your function runs, including their status, output, and execution time.
• Extended Trace Spans: Query the spans associated with your function runs, providing more information about the execution of your functions.

In addition to new datasources, we've also added support for new functions and improved syntax support to make it easier to query your data.

We've also improved the Insights sidebar with new features including:

• Insights AI — An assistant to help write your queries from plain English descriptions.
• Schema Explorer — A sidebar utility that shows available tables and event schemas.

Check out the Insights documentation for more details on the new features.

Realtime is now a first-class part of the TypeScript SDK. Channels, topics, publishing, and subscribing all have an improved DX, along with an updated useRealtime React hook.

See the TypeScript realtime docs for the full overview and API reference.

The legacy @inngest/realtime package still works for existing apps but is now deprecated in favor of the built-in realtime APIs in inngest, inngest/realtime, and inngest/react.

The TypeScript SDK v4 is now generally available!

This is a major version with breaking changes, but for most apps the migration is trivial.

Install with npm install inngest@latest.

For full details on changes and how to migrate from v3:

• Announcement blog post
• Migration guide

You can now zoom into specific time ranges in traces for long-running functions with short steps using the timeline header’s time brush. Drag the handles to narrow the view, move the selection to pan across the timeline, click outside to expand it, or use the reset button to return to the full range. Time markers update dynamically and all bars rescale to fit the visible window.

We’ve also added more information to help you inspect what your functions return, including a new Headers tab that shows the response headers returned by your SDK endpoint.

The TypeScript SDK v4 is now available in beta! Major improvements include:

• Rewritten middleware — Hooks are more intuitive, less overloaded, and enable new use cases.
• Better schemas — Runtime event data validation with Standard Schema support (not just Zod!).
• Faster by default — Parallel step optimization and checkpointing are both enabled by default, leading to fewer requests and lower latency.
• Improved logging — Structured logging (Pino-style) and cleaner separation of internal vs. app logs.
• Cleaner API — Triggers in the options object, lazy init for edge runtimes, and more compile-time safety

This is a major version with breaking changes, but for most apps the migration is trivial.

Install the beta with npm install inngest@beta.

More info:

• Announcement blog post
• Migration guide

We've released Inngest Agent Skills — pre-built skills for AI coding agents like Claude Code, Cursor, and Windsurf that provide up-to-date guidance on building with Inngest.

Six skills are available covering the full Inngest development workflow:

• inngest-setup — Project configuration and SDK installation
• inngest-events — Event design, naming conventions, and idempotency
• inngest-durable-functions — Function creation with triggers, retries, and error handling
• inngest-steps — Workflow composition with step methods
• inngest-flow-control — Concurrency, throttling, rate limiting, and batching
• inngest-middleware — Cross-cutting concerns and dependency injection

Pair with the Dev Server MCP integration for a complete AI-powered write, test, and debug loop.

Learn more in the Agent Skills documentation or check out the inngest-skills repo on GitHub.

Our official Helm chart is now published as an OCI artifact for easy installation and upgrades for self-hosting Inngest.

The latest release includes improved labels support with applying Kubernetes best practices and improved probes.

Check out the release for more information.

Durable Endpoints bring Inngest's durability directly into your API handlers. Wrap your endpoint code with inngest.endpoint() and use step.run(), each step automatically gets retries, recovery, and observability, without leaving your endpoint code.

Durable Endpoints are low-latency and unbreakable API endpoints, with:

• Zero wasted keystrokes: Wrap code in step.run(), and you're done. No queues to configure, no workers to deploy.
• Automatic recovery: Steps checkpoint as they complete. Failures retry from the last successful step, not from scratch.
• Built-in observability: See exactly what's running, what failed, and why.
• Low latency by design: Powered by Checkpointing for fast execution.

Durable Endpoints is available now in public beta for Next.js and Bun.

Read the blog post · Get started with the documentation

Our docs now have quick actions to copy or open the current page in Markdown format. You can also open a new conversation with the markdown URL in Claude, ChatGPT or other LLM providers. The Markdown format reduces the amount of context needed to be sent to LLMs and coding agents.

The llms.txt file now also includes the markdown URLs for each page, reducing the required context

We're thrilled to release the developer preview of a new Inngest's orchestration engine capability: Checkpointing. By enabling checkpointing, Inngest workflows stay durable while achieving near-zero inter-step latency.

Checkpointing is designed to support the growing need for real-time Inngest workflows—such as AI workflows—powering interactive and reliable user experiences.

We've been dogfooding Checkpointing for several weeks, and the results are astonishing: near-zero inter-step latency and an overall 50% reduction in workflow duration.

Checkpointing is currently available in developer preview as an opt-in configuration at the client or function level.

Get started and learn more about Checkpointing.

We are excited to announce the release of MCP Integration, bringing AI-assisted development workflows to the Inngest dev server. Connect Claude Code, Cursor, and other AI assistants directly to your local Inngest functions for seamless testing and debugging.

The MCP server provides comprehensive access to your development environment with 8 powerful tools:

• Event management - Send events and discover registered functions
• Real-time monitoring - Track function execution and debug failures with detailed traces
• Direct function invocation - Execute functions synchronously and get immediate results
• Documentation access - Search and read Inngest documentation offline
• Integration testing - Poll multiple runs to verify complex workflows

Learn more in the MCP Integration documentation.

Webhooks are now more flexible with the addition of x-www-form-urlencoded and multipart/form-data content types. When sending a request with either of these content types, your webhook transform will have access to both a JSON object representation of the body and the raw body as a string.

For example, if you send a webhook request like the following:

curl https://inn.gs/e/REDACTED \
  -H "content-type: application/x-www-form-urlencoded" \
  -d "name=Alice&messages=hello&messages=world"

And your webhook transform looks like this:

function transform(json, headers, queryParams, raw) {
  return {
    name: "hi",
    data: { json, raw },
  };
};

Then the resulting event data will be:

{
  "json": {
    "messages": ["hello", "world"],
    "name": ["Alice"]
  },
  "raw": "name=Alice&messages=hello&messages=world"
}

Note that the JSON object's values are always arrays of strings.

We've released realtime support for Python (v0.5.9), enabling developers to build interactive applications that push updates from durable workflows to the browser.

Read the full blog post or explore the realtime documentation for more details.

Our TypeScript SDK now supports the Standard Schema interface, which allows you to now use Zod 4 to define your event payload types. The Standard Schema interface is a standard way to define event payload types in a way that is easy to use and understand. This means that schemas can now be defined with:

• Zod
• Valibot
• ArkType
• joi
• and more!

Upgrade to SDK v3.42.0 or higher and check out the documentation for more information.

We've released useAgent and useChat, hooks for streaming realtime updates from your AgentKit agents to the browser.

Read the full blog post or explore the documentation and guides for more information.

We've released Insights, a new feature that allows you to query your events with SQL directly in the Inngest dashboard. This initial release is focused on querying events, but support for querying runs and other data sources will be added in the future.

Read the full blog post for more details.

We've released the latest Go SDK (v0.14.0), enabling you to use step.run in your REST APIs. You can now make any API endpoint durable and observable with a couple lines of code. TypeScript SDK support is coming soon.

Read the full blog post or dive into the docs for more details.

Advanced event filters are now available using a CEL expression. Access the new search functionality by clicking the "Show search" button on the Events page.

Learn more about how to use this feature and view the list of searchable properties in our docs

Singleton Functions now supports a new cancel mode in addition to the existing skip mode.

When using mode: "cancel", new function runs will cancel any existing run with the same key and start fresh, ensuring only the most recent execution proceeds. This is particularly useful for scenarios where you want to process the latest data and can safely discard in-progress work.

const latestDataSync = inngest.createFunction({
  id: "latest-data-sync",
  singleton: {
    key: "event.data.user_id",
    mode: "cancel",
  }  
},
{ event: "data-sync.start" },
async ({ event }) => {
  // Any existing run for this user will be cancelled
  const payload = await fetchLatestUserData(event.data.user_id);
  await applyRealTimeUpdates(payload);
});

We are excited to announce the release of Connect, a new feature that allows you to connect your application to Inngest over one or multiple outbound persistent connections, bringing:

• Lower latency - No need for multiple HTTP requests to Inngest to process a single function.
• Elastic horizontal scaling - Easily add more capacity by running additional workers.
• Ideal for container runtimes - Deploy on Kubernetes or ECS without the need of a load balancer for inbound traffic
• Simpler long running steps - Step execution is not bound by platform http timeouts.

Learn more in the announcement blog post.

You can now export your Inngest metrics to Datadog. This enables you and your team to use Inngest's metrics in your existing monitoring and alerting systems.

To get started, visit the new Datadog page in the "Integrations" section of the Inngest dashboard and follow the instructions to get the scrape config for the environment that you want to export metrics from.

Learn more in our announcement blog post.

Singleton Functions is a new Flow Control feature that allows exclusive execution of an Inngest function.

Unlike Rate Limiting which discard events given a configured time window, Singleton Functions discard events (or cancel runs) only if an execution is already running.

Learn more about Singleton Functions in the documentation page.

We've added a new event history explorer to the Inngest dashboard. This view allows you to view all events across an entire environment. A filtered view is also available when viewing a specific event type.

The new view is powered by a new API and database which should deliver faster loading times overall.

We are excited to announce the release of Realtime, a new feature that allows you to stream updates from your Inngest functions to your users.

Realtime is built upon Inngest's protocol, ensuring secure, low-latency and at-most-once delivery of messages.

Read more about the new Realtime APIs available in our TypeScript and Go SDKs in the release blog post.

We are thrilled to release Fetch, a set of new APIs to make durable HTTP requests within an Inngest function. Now available in our TypeScript SDK, the step.fetch() API and the fetch() utility enable you to make requests to third-party APIs or fetch data in a durable way by offloading them to the Inngest Platform.

const processFiles = inngest.createFunction(
  { id: "process-files" },
  { event: "files/process" },
  async ({ step }) => {
    // The request is offloaded to the Inngest Platform
    const response = await step.fetch("https://api.example.com/files", {
      method: "GET",
      headers: {
        "Authorization": `Bearer ${process.env.API_KEY}`
      }
    })

    // Your Inngest function is resumed here with the response
    await step.run("process-file", async (file) => {
      const body = await response.json()
      // body.files
    })
  }
)

Read more about the new Fetch APIs in the release blog post.

The old Events list in Cloud is now called Event Types, with improved usability!

You can now search by name and filter by status — active or archived.

Coming soon: A new Events stream page where you can view all received events in one place.

The CMD+K quick search in Cloud is now even more powerful!

In addition to searching by event and run ID, you can now find results by app, event, and function names, making it easier than ever to locate what you need in each environment.

We've also added quick access to useful pages (like signing keys) and top actions (such as adding an app), making navigation even faster.

Coming soon: the ability to view recent searches. What other actions would you like to access instantly? Let us know!

We're introducing a new run traces view!

The run traces view has been redesigned to better organize and visualize traces for complex workflows, especially Agentic AI workflows that may involve many steps with larger payloads and outputs.

Trace visualizations are now more interactive. You can drill into and expand individual run steps to see and work with inputs, outputs and errors.

If at any time you want to jump back to the legacy runs view there is a toggle to do that at the top of the view.

We're introducing a highly requested feature: dark mode!

You can now change your theme in the settings dropdown, and select between light, dark or your system preference.

Read more about the design and implementation process of this feature in the blog.

You can now export your Inngest metrics to Prometheus. This enables you and your team to use Inngest's metrics in your existing monitoring and alerting systems.

Several metrics are now available to export, including:

• inngest_function_run_scheduled_total
• inngest_function_run_started_total
• inngest_function_run_ended_total
• Read the full list of metrics in the docs.

To get started, visit the new Prometheus page in the "Integrations" section of the Inngest dashboard and follow the instructions to get the scrape config for the environment that you want to export metrics from.

It's available on all paid plans today. Read more information in the docs.

The new webhooks management API endpoints are now available as part of the Inngest REST API.

You can now create, update, and delete webhooks for your Inngest account, including updating transform functions. This enables you to:

• Manage webhook transforms within your codebase, including adding unit tests for your transforms.
• Programmatically create, update, and delete webhooks for customers or integrations.

To help you get started, we created a webhook transform sync demo repo that shows how you can test and sync transforms between your codebase and Inngest.

Read more information in the API docs.

You can now archive events in your Inngest environment. This is useful if you want to hide old events that you no longer use.

Archiving events does not prevent them from being received, they only hide them from your dashboard. If an archived event is received, it will be unarchived automatically.

Postgres support is now available for self-hosted Inngest. This enables you to use Postgres as your event storage backend, instead of the default SQLite. This will be marked as experimental until additional testing is completed and feedback is received.

Available in the Inngest CLI v1.4.0 with the --postgres-uri flag.

A new system event has been added to allow you to write functions that run after other function runs are cancelled. This enables you to handle cancelled runs gracefully.

• Example: Cleanup after function cancellation
• inngest/function.cancelled - System event reference