Rank #4 of 6 in Durable Execution Engines
Inngest
Open SourceInngest, Inc.
Install
Try itExperimental
See what an agent can do with Inngest before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si https://api.inngest.com/v1/eventsrecorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agent workloads — stories about agent workloads in this arenaAgent workloadsevidence →
Stories about agent workloads in this arena
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Developer experience — stories about developer experience in this arenaDeveloper experienceevidence →
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loopevidence →
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debuggingevidence →
Stories about observability debugging in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hostingevidence →
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scaleevidence →
Stories about performance scale in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recoveryevidence →
Stories about reliability recovery in this arena
Triggers scheduling — stories about triggers scheduling in this arenaTriggers schedulingevidence →
Stories about triggers scheduling in this arena
Versioning deployment — stories about versioning deployment in this arenaVersioning deploymentevidence →
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoringevidence →
Stories about workflow authoring in this arena
Story verdicts — every judged story with its evidenceStory verdicts
What’s free: 1 free · 0 paid · 0 enterprise · 40 not stated in evidence
Follow the green: where the map greys out is where Inngest stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agent workloads — stories about agent workloads in this arenaAgent workloads
Stories about agent workloads in this arena
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
✓9/10
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
~6/10
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
—–
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
✓8/10
unlocks → Scoped API keys · Machine-readable spec · Versioning policy · I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
Subscribe to events via webhooks
✓8/10
Build against official SDKs
✓8/10
Issue scoped/least-privilege API credentials for an agent
—–
Connect an agent via an official MCP server
✓8/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—0/10
Test against a sandbox environment without touching production data
~5/10
Explore an interactive API reference with runnable examples
—0/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
—0/10
Operate the product with natural-language commands
~6/10
Plug MCP servers into this product so it can use their tools
—0/10
Get AI-generated insights and suggestions from my data inside the product
—0/10
Set up automations that run autonomously in the background
✓9/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Developer experience — stories about developer experience in this arenaDeveloper experience
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loop
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debugging
Stories about observability debugging in this arena
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
~5/10
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
~5/10
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
✓8/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hosting
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scale
Stories about performance scale in this arena
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
✓8/10
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
~3/10
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
~5/10
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recovery
Stories about reliability recovery in this arena
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
~5/10
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
✓9/10
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
✓9/10
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
✓9/10
Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling
Stories about triggers scheduling in this arena
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
✓9/10
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
~4/10
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
~5/10
Versioning deployment — stories about versioning deployment in this arenaVersioning deployment
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring
Stories about workflow authoring in this arena
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
✓9/10
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
~6/10
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
~5/10
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 9/10 | Xcommunity | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Xcommunity | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Cclaimed | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | partial | 5/10 | Xcommunity | |
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact C Recovery | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | fullfree | 9/10 | Xcommunity | |
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives C Approvals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 3 | full | 9/10 | Cclaimed | |
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding C Retries | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | full | 9/10 | Xcommunity | |
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run C Agent loops | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 3 | full | 9/10 | Xcommunity | |
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL C Authoring | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 3 | full | 9/10 | Xcommunity | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | full | 8/10 | Xcommunity | |
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter C Run visibility | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 3 | full | 8/10 | Xcommunity | |
I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism C Versioning | platform engineer | Versioning deployment — stories about versioning deployment in this arenaVersioning deployment | 3 | full | 8/10 | Cclaimed | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | full | 7/10 | Xcommunity | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | partial | 4/10 | Xcommunity | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute C Long running | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | full | 9/10 | Xcommunity | |
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions C Events | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | full | 9/10 | Xcommunity | |
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow C Signals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 2 | full | 9/10 | Cclaimed | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | full | 9/10 | Xcommunity | |
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest C Flow control | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | full | 8/10 | Cclaimed | |
I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network C Deployment model | platform engineer | Operations hosting — stories about operations hosting in this arenaOperations hosting | 2 | full | 7/10 | Cclaimed | |
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code C Ai integrations | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | partial | 6/10 | Cclaimed | |
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination C Composition | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | partial | 6/10 | Cclaimed | |
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps C Local dev | backend developer | Developer experience — stories about developer experience in this arenaDeveloper experience | 2 | partial | 6/10 | Xcommunity | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 5/10 | Tprobed | |
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs C Language coverage | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | partial | 5/10 | Xcommunity | |
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover C Replay | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 2 | partial | 5/10 | Cclaimed | |
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs C Schedules | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | partial | 5/10 | Cclaimed | |
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending C Exactly once | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | partial | 5/10 | Cclaimed | |
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss C Scaling | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | partial | 5/10 | Cclaimed | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | partial | 4/10 | Cclaimed | |
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | partial | 3/10 | Cclaimed | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | partial | 3/10 | Cclaimed | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | disputed | 3/10 | Dcontradicted | |
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes C Streaming | ai-native user | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | none | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave C Metrics | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 1 | partial | 5/10 | Cclaimed | |
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want C Flow shaping | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 1 | partial | 4/10 | Cclaimed | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | partial | 4/10 | Cclaimed | |
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue C Prioritization | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 1 | partial | 3/10 | Cclaimed |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 29 stories with headroom
What would move Inngest’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productDelegate tasks to a built-in AI assistant inside the product
nonemoves Built-in AIimpact 45
Inngest offers AgentKit (a framework for building external AI agents) and an MCP server so coding agents can inspect/operate Inngest, but there is no evidence of a built-in AI assistant inside the Inngest product itself that a user can delegate tasks to.
Agenticness — how well agents can access and operate the productPlug MCP servers into this product so it can use their tools
nonemoves agent-readyimpact 45
The only MCP evidence shows Inngest exposing itself as an MCP server so external coding agents (Claude Code, Cursor, etc.) can inspect/operate Inngest — the reverse direction of this story.
Agenticness — how well agents can access and operate the productGet AI-generated insights and suggestions from my data inside the product
nonemoves Built-in AIimpact 30
Inngest's 'AI Overview' dashboard surfaces usage/cost/performance metrics from gen_ai telemetry, but this is a metrics visualization, not AI-generated insights or suggestions derived from the user's own data.
Agenticness — how well agents can access and operate the productIssue scoped/least-privilege API credentials for an agent
nonemoves agent-readyimpact 30
No evidence of scoped/least-privilege API credential issuance for agents; Inngest docs cover encryption middleware, SOC2 compliance, and webhooks but nothing about generating restricted-scope API keys or tokens for agent identities.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
Inngest documents a REST API (api-docs.inngest.com) but the evidence pack shows explicit probe failures for an OpenAPI/Swagger spec and a docs.md, with no mention of interactive 'try it' examples or runnable API console; nothing indicates an explorable, runnable API reference exists.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
Probes explicitly checked for an OpenAPI/swagger spec (openapi.json, swagger.json, etc.) and all returned 404, and no docs.md/machine-readable spec was found; while a REST API is documented (api-docs.inngest.com), there is no evidence of a downloadable OpenAPI or equivalent spec.
Agenticness — how well agents can access and operate the productRely on versioned APIs with a documented deprecation policy
nonemoves API qualityimpact 30
While Inngest exposes a REST API (inngest-docs-7) and SDK version paths (e.g.
Privacy posture — data-handling and privacy storiesOpt out of telemetry and usage tracking
nonemoves PA Scoreimpact 20
No evidence in the pack addresses telemetry/usage-tracking opt-out settings for Inngest itself; self-hosting and SOC2 docs discuss data control and infrastructure but do not mention any telemetry opt-out mechanism.
Showing the top 8 of 29 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map9 surfaces · 43 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
docs42 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- Point an agent at llms.txt or agent-oriented docs
- Run the product headlessly / in CI for automation
- Connect an agent via an official MCP server
- Use an official CLI
- Drive the product through a documented public API
- Build against official SDKs
- Subscribe to events via webhooks
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- Test against a sandbox environment without touching production data
- Perform bulk operations across many items at once
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- Version, review, and roll back my automations
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Do everything through the API that I can do in the UI
- Export all of my data in open formats and leave
- Self-host the core product
- I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
- I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
- I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Choose where my data is stored (region/residency)
- Control data retention and deletion
- Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
- I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Hacker News18 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- Run the product headlessly / in CI for automation
- Build against official SDKs
- Set up automations that run autonomously in the background
- Test against a sandbox environment without touching production data
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Export all of my data in open formats and leave
- Read the product's source under an open license
- Self-host the core product
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Docs markdown docs15 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- Use an official CLI
- Build against official SDKs
- Set up automations that run autonomously in the background
- Version, review, and roll back my automations
- A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Do everything through the API that I can do in the UI
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
GitHub README8 stories
- Run the product headlessly / in CI for automation
- Export all of my data in open formats and leave
- Read the product's source under an open license
- Self-host the core product
- I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Choose where my data is stored (region/residency)
- Control data retention and deletion
api-docs.inngest.com8 stories
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Build against official SDKs
- Test against a sandbox environment without touching production data
- Perform bulk operations across many items at once
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Do everything through the API that I can do in the UI
- Export all of my data in open formats and leave
Changelog docs4 stories
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- Do everything through the API that I can do in the UI
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
OpenAPI spec3 stories
llms.txt2 stories
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -si https://api.inngest.com/v1/eventsreproduced$ curl -si https://api.inngest.com/v1/events
HTTP/2 401
date: Thu, 10 Sep 2026 18:41:03 GMT
content-type: text/plain; charset=utf-8
set-cookie: jwt=; Path=/; Domain=inngest.com; Expires=Thu, 10 Sep 2026 18:40:03 GMT; Max-Age=0; HttpOnly; Secure; SameSite=Lax
vary: Origin
vary: Origin
x-inngest-sdk: go:0.16.1
x-inngest-server-kind: cloud
x-run-id: 01M269Z4J85YPC3T3RTWW4RZ4S
{"error":"Unauthorized","status":401}
$npx -y inngest-cli@latest --versionreproduced$ npx -y inngest-cli@latest --version inngest version 1.44.0-a54673a45
$curl -si -X POST https://api.inngest.com/mcp -H 'Content-Type: application/json' -d '<jsonrpc initialize>'reproduced$ curl -si -X POST https://api.inngest.com/mcp -H 'Content-Type: application/json' -d '<jsonrpc initialize>'
HTTP/2 401
date: Thu, 10 Sep 2026 18:41:02 GMT
content-type: application/json
vary: Origin
www-authenticate: Bearer realm="inngest-mcp", error="invalid_[redacted]", error_description="Missing or invalid access [redacted]"
x-inngest-sdk: go:0.16.1
x-inngest-server-kind: cloud
x-run-id: 01M269Z493XP07KAJ629DPJX80
{"error":"invalid_[redacted]","error_description":"Missing or invalid access [redacted]"}
$curl -sL https://www.inngest.com/docs-markdown/learn/how-functions-are-executed | head -8reproduced$ curl -sL https://www.inngest.com/docs-markdown/learn/how-functions-are-executed | head -8 # How Inngest functions are executed: Durable Execution Most systems that offer durable execution require you to manage separate worker infrastructure, learn custom runtimes, or rewrite your application code to fit a specific programming model. Inngest takes a different approach: you write standard TypeScript, Python, or Go functions using a simple SDK, and Inngest handles execution durability, state persistence, retries, and flow control for you. There are no queues to configure, no workers to deploy, and no infrastructure to manage. Your functions run on your own compute, in any environment, including serverless. One of the core features of Inngest is Durable Execution. Durable Execution allows your functions to be fault-tolerant and resilient to failures. The end result is that your code, and therefore, your overall application, is more reliable. This page covers what Durable Execution is, how it works, and how it works with Inngest functions.
$curl -s https://www.inngest.com/llms.txt | head -6reproduced$ curl -s https://www.inngest.com/llms.txt | head -6 # Inngest > Inngest is the durable workflow engine for AI applications. It provides step-level retries, event coordination, throttling, concurrency controls, and human-in-the-loop patterns. Write reliable background jobs and multi-step AI pipelines as regular code, with built-in observability and zero infrastructure to manage. - [Documentation](https://www.inngest.com/docs-markdown/) - [Full documentation as single file](https://www.inngest.com/llms-full.txt)
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
10 of 18 testable claims verified · 1 contradicted → integrity 44/100
25 distinct capability claims found in Inngest’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
10
Verified
7
Unverified
1
Contradicted
25
Undersold
Verified (14)
“Fully managed durability, state persistence, retries, and flow control with no queues or workers to set up”
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intactfullproof ↗
“Steps memoize results and retry independently, letting workflows resume from the last successful checkpoint”
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intactfullproof ↗
“Steps memoize results and retry independently, letting workflows resume from the last successful checkpoint”
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffoldingfullproof ↗
“MCP clients like Claude Code, Codex, or Cursor can connect to inspect and operate Inngest”
“REST API to programmatically interact with events, function runs, and environments”
Drive the product through a documented public APIfullproof ↗
“Official CLI to inspect runs, fetch traces, invoke functions, and give coding agents terminal access”
“Self-hosting option for developers who don't want the hosted platform”
“Jest-compatible testing API mocks function state, steps, and inputs across major test frameworks”
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked stepspartialproof ↗
“Functions and steps automatically retry up to 4 times by default until they succeed”
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffoldingfullproof ↗
“Durable Endpoints turn API logic into fault-tolerant endpoints by wrapping it in durable steps”
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intactfullproof ↗
“Automatic capture of metrics, traces, event logs, and per-step timing for every run”
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filterfullproof ↗
“Every agent step and tool call is checkpointed so a crashed run resumes at its last completed step, not from scratch”
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
“Guide for building ReAct-style agent loops where each reason/act/observe iteration is a durable, retriable step”
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
“Write workflow functions in TypeScript, Python, or Go with built-in steps, queueing, scaling, and observability handled for you”
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKspartialproof ↗
Unverified (9)
“AgentKit framework for building AI agents, from single model calls to multi-agent tool-using systems”
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue codepartialproof ↗
“Create unique webhook consumer URLs for any third-party service”
“Step concurrency limits can be scoped per key, e.g. per user id”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restfullproof ↗
“Hard rate limiting skips function runs that exceed a configured threshold within a time window”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restfullproof ↗
“Cron schedules support timezones for scheduling work at the right local time”
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runspartialproof ↗
“step.waitForEvent() pauses a run until a matching event arrives or a timeout elapses”
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflowfullproof ↗
“Deploy new function code without explicit version markers or manual migration logic”
I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinismfullproof ↗
“step.ai.wrap() wraps OpenAI, Anthropic, and Vercel AI SDK calls as durable steps with prompt/token observability”
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue codepartialproof ↗
“Deploy functions to your own infrastructure and sync them with the managed platform or a self-hosted server”
I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my networkfullproof ↗
Contradicted (1)
“AI Overview dashboard surfaces usage, cost, and performance insights from captured AI call metadata”
Get AI-generated insights and suggestions from my data inside the productnoneproof ↗
Undersold (25)
Point an agent at llms.txt or agent-oriented docspartialproof ↗
Run the product headlessly / in CI for automationfullproof ↗
Set up automations that run autonomously in the backgroundfullproof ↗
Operate the product with natural-language commandspartialproof ↗
Test against a sandbox environment without touching production datapartialproof ↗
Perform bulk operations across many items at oncepartialproof ↗
Define rules that trigger actions automatically on eventsfullproof ↗
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrivesfullproof ↗
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehavepartialproof ↗
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recoverpartialproof ↗
Do everything through the API that I can do in the UIpartialproof ↗
Export all of my data in open formats and leavepartialproof ↗
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queuepartialproof ↗
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker losspartialproof ↗
Choose where my data is stored (region/residency)partialproof ↗
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sendingpartialproof ↗
A workflow can sleep or wait for days to months without holding a server, connection, or billable computefullproof ↗
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functionsfullproof ↗
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually wantpartialproof ↗
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSLfullproof ↗
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordinationpartialproof ↗
Claims outside our story set (2)
Real capability claims found in Inngest’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Sessions automatically propagate from a run to any child runs it triggers”
source ↗“Optional encryption middleware lets you bring your own key for added data protection”
source ↗
Business model
Hobby free: 50K executions/mo, 5 concurrent steps. Pro from $99/mo: 1M executions included, 100+ concurrent steps, +$25 per 25 concurrency. Enterprise custom (SAML, RBAC). Self-host free (SSPL, source-available).
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
Agent surface uptime MCP up · llms.txt up (tracking since Sep 11 '26)