Inngest vs Hatchet

Agent loops

1. agent builderI run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run

   weight 3 · round to Inngest
   Inngest✓fullcommunity9/10

   Inngest has dedicated docs for durable agent loops: checkpointed steps that resume from the last successful point mid-run (docs-21, docs-33), a ReAct-style agent-tool-loop guide with retriable steps (docs-23), step.ai.wrap() for wrapping model calls as durable/observable steps (docs-22), sub-agent delegation and human-in-the-loop pause/resume patterns (docs-34, docs-35), plus general durable-execution/retry/memoization mechanics (docs-2, docs-15, docs-26). Community feedback corroborates reliability of the underlying durable execution engine in production use (inngest-comm-1, inngest-comm-5, inngest-comm-9). Missing for 10: independent hands-on validation specifically of agent-loop crash recovery (not just general durable functions) and more detail on tool-call-level retry semantics distinct from generic step retries.

   • [claimed-docs] “Every step, every tool call, every decision the agent makes is checkpointed as it happens. If the process dies at step 7 of 12, the agent pi…”
   • [claimed-docs] “If the process dies at step 7 of 12, the agent picks up at step 7 — not step 1. If the agent needs to wait three hours for a human to approv…”
   • [claimed-docs] “This guide walks you through building a ReAct-style agent loop (Reason → Act → Observe → Repeat) where each iteration is a durable, retriabl…”
   • [claimed-docs] “step.ai.wrap() wraps other AI SDKs (OpenAI, Anthropic, and Vercel AI SDK) as a step, augmenting the observability of your Inngest Functions …”
   • [claimed-docs] “Use step.waitForEvent() to pause agent execution for human approval, then resume or abort based on the response.”
   • [claimed-docs] “Delegation gives sub-agents their own context window, tools, and token budget. A sub-agent can be modeled as a separate Inngest function tha…”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “By default, in addition to the initial attempt, Inngest will retry a function or a step up to 4 times until it succeeds.”
   • [community] “Really great product, I'm using inngest since 2-3 months and it definitely solved our problem. We needed a scheduling, queue, trigger soluti…”
   • [community] “I implemented Inngest to handle our video migration queues... complete breeze. Loved the balance between the amount of complexity that's abs…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed7/10

   Hatchet is explicitly positioned as an orchestration engine for AI agents and durable workflows, with first-party docs on retry policies, durability, concurrency, cron/scheduled runs, and dedicated cookbooks showing Claude Agent SDK / OpenAI Agents SDK integration and a support-agent workflow example, matching the checkpointed/retried step model for agent loops. Missing for 10: independent/hands-on evidence of crash-mid-run recovery specifically for LLM tool-call loops, and more detail on how model/tool call state is checkpointed rather than just task-level retries.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Support Agent”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [claimed-docs] “Concurrency”

   proof ↗⚑ flag

Ai integrations

1. agent builderFirst-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code

   weight 2 · round drawn
   Inngest~partialclaimed6/10

   Inngest ships concrete first-party wrapping of AI SDKs (step.ai.wrap for OpenAI, Anthropic, Vercel AI SDK) and its own AgentKit framework, plus durable-agent patterns (checkpointing, human-in-the-loop, sub-agent delegation) that give agent steps durability without manual glue code. However, coverage of other agent frameworks (LangChain, LlamaIndex, CrewAI, etc.) and model providers beyond the three named is not evidenced, and no independent/hands-on corroboration of these specific AI integrations exists beyond vendor docs. missing for 10: broader agent-framework integrations beyond AgentKit/step.ai.wrap, more model-provider coverage, and independent verification of these AI-specific wrappers.

   • [claimed-docs] “step.ai.wrap() wraps other AI SDKs (OpenAI, Anthropic, and Vercel AI SDK) as a step, augmenting the observability of your Inngest Functions …”
   • [claimed-docs] “AgentKit is a framework to build AI Agents, from single model inference calls to multi-agent systems that use tools.”
   • [claimed-docs] “Every step, every tool call, every decision the agent makes is checkpointed as it happens. If the process dies at step 7 of 12, the agent pi…”
   • [claimed-docs] “This guide walks you through building a ReAct-style agent loop (Reason → Act → Observe → Repeat) where each iteration is a durable, retriabl…”
   • [claimed-docs] “If the process dies at step 7 of 12, the agent picks up at step 7 — not step 1. If the agent needs to wait three hours for a human to approv…”
   • [claimed-docs] “Delegation gives sub-agents their own context window, tools, and token budget. A sub-agent can be modeled as a separate Inngest function tha…”

   proof ↗⚑ flag

   Hatchet~partialclaimed6/10

   Hatchet documents first-party cookbooks/integrations for the Claude Agent SDK and OpenAI Agents SDK (exposing Hatchet workflows/tasks as durable tools these frameworks can invoke) plus an MCP-based agent-tools pattern and a support-agent cookbook, directly supporting durability for agent steps without custom glue code for those specific frameworks. However, coverage is limited to two named agent SDKs and MCP — there's no evidence of broader first-party wrappers for other AI SDKs (e.g., LangChain, LlamaIndex) or direct model-provider clients (OpenAI/Anthropic APIs) beyond the agent-SDK cookbooks. Missing for 10: integrations/cookbooks for additional AI SDKs and model providers, and independent confirmation of ease-of-use/durability in production for these integrations.

   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [claimed-docs] “Support Agent”

   proof ↗⚑ flag

Streaming

1. ai-native userI stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes

   weight 2 · round drawn
   Inngest—none0/10

   Evidence covers durability, step checkpointing, observability dashboards, and AI-call tracing, but nothing describes a mechanism (e.g., websockets, SSE, pub/sub API) for streaming step updates or model tokens live into a user-facing frontend during execution.

   ⚑ flag

   Hatchet—none0/10

   Hatchet's evidence covers real-time observability via its TUI/dashboard and general monitoring/logging, but nothing describes a mechanism for streaming step updates or model tokens into a consumer's own frontend as a workflow executes (no SSE/websocket API, event-stream docs, or token-streaming cookbook is cited). Given Hatchet explicitly targets AI-agent orchestration, this is a fair axis to expect evidence for, but none is present.

   ⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Hatchet
   Inngest~partialprobed6/10

   A confirmed live llms.txt exists at inngest.com/llms.txt returning HTTP 200 with structured agent-friendly summary content, directly satisfying the core ask. However, docs.md (markdown docs endpoint) returns 404, and there's no broader agent-oriented docs.md/site-wide markdown mirror confirmed, only the single llms.txt file. Missing for 10: verified docs.md or per-page markdown mirrors, independent confirmation that agents successfully consume the llms.txt for grounding, and broader agent-oriented documentation format beyond the single root file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.inngest.com/llms.txt # Inngest > Inngest is the durable workflow engine for AI applications. It pro…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.inngest.com/docs.md”

   proof ↗⚑ flag

   Hatchet✓fullprobed9/10

   A direct probe confirms llms.txt is live at https://docs.hatchet.run/llms.txt returning HTTP 200 with structured documentation content, which an agent could be pointed at directly. Missing for 10: no independent/community corroboration of agents actually consuming it in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.hatchet.run/llms.txt # Hatchet Documentation > Hatchet is a distributed task queue and workflow en…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Inngest✓fullcommunity8/10

   Inngest functions are plain code triggered by events/cron/CLI/API and run on your own infra or self-hosted servers, with a REST API and CLI for invoking functions, fetching traces, and running tests headlessly in CI (inngest-docs-7, inngest-docs-8, inngest-docs-9, inngest-docs-14, inngest-gh-1). Community reports confirm production use in automated background/queue pipelines. Missing for 10: no explicit CI pipeline example/GitHub Actions integration doc, and no independent benchmark of headless CI runs.

   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”
   • [claimed-docs] “While the easiest way to get started with Inngest is using our hosted platform... we understand that developers may want to self-host for a …”
   • [claimed-docs] “This allows you to mock function state, step tooling, and inputs with a Jest-compatible API supporting all major testing frameworks, runtime…”
   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”
   • [community] “I implemented Inngest to handle our video migration queues... complete breeze. Loved the balance between the amount of complexity that's abs…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Hatchet is a headless orchestration engine by design: workers run as background processes (hatchet worker dev / production worker run), SDKs exist for Python/TypeScript/Go/Ruby for scripted automation, and self-hosting/control-plane docs plus cron/scheduled runs support CI-driven and unattended execution. missing for 10: explicit CI pipeline examples (e.g., GitHub Actions integration) and independent confirmation of headless CI usage beyond docs.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected.”
   • [claimed-docs] “Running Workers Locally”
   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Inngest—none0/10

   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. There is no evidence that Inngest or its AgentKit framework can act as an MCP client, ingesting external MCP servers' tools for its own agents to use.

   • [claimed-docs] “Connect Claude Code, Codex, Cursor, or another MCP client to inspect and operate Inngest from your coding agent.”
   • [probe] “official MCP server documented at https://www.inngest.com/docs/ai-dev-tools/mcp”
   • [claimed-docs] “AgentKit is a framework to build AI Agents, from single model inference calls to multi-agent systems that use tools.”

   proof ↗⚑ flag

   Hatchet—none0/10

   Hatchet's MCP-related evidence (hatchet-docs-7, hatchet-docs-34, hatchet-docs-36, hatchet-docs-37) describes the opposite integration direction: exposing Hatchet's own workflows/tasks as tools that external agent frameworks (Claude Agent SDK, OpenAI Agents SDK) can invoke via MCP. There is no evidence that Hatchet itself can plug in external MCP servers to consume their tools within its workflows or workers.

   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Inngest
   Inngest✓fullprobed8/10

   Inngest documents an official MCP server (inngest.com/docs/ai-dev-tools/mcp) explicitly designed to let MCP clients like Claude Code, Codex, and Cursor connect and inspect/operate Inngest, confirmed via a live probe. As Inngest is a workflow platform rather than an agent itself, this axis applies and is met by first-party documentation. Missing for 10: independent/hands-on confirmation that the MCP server works reliably in practice.

   • [claimed-docs] “Connect Claude Code, Codex, Cursor, or another MCP client to inspect and operate Inngest from your coding agent.”
   • [probe] “official MCP server documented at https://www.inngest.com/docs/ai-dev-tools/mcp”

   proof ↗⚑ flag

   Hatchet✓fullclaimed7/10

   Hatchet's official docs describe an MCP integration cookbook that exposes Hatchet workflows and standalone tasks as tools invocable by agent frameworks like the Claude Agent SDK and OpenAI Agents SDK, i.e. an official MCP server surface for connecting agents. This is first-party documented but only via a cookbook page rather than a deeply spec'd MCP server reference, and there's no independent/hands-on corroboration. Missing for 10: dedicated MCP server reference docs beyond the cookbook, and independent verification of it working end-to-end.

   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   Inngest✓fullprobed8/10

   Inngest ships an official CLI documented at /docs/cli that lets users inspect runs, fetch traces, invoke functions, and even give coding agents access to Inngest data from the terminal, plus a dedicated guide on debugging failed runs entirely from the CLI — directly serving AI-native/agentic workflows. missing for 10: independent hands-on community confirmation of the CLI specifically (community quotes reference dev server/DX generally, not the CLI by name).

   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”
   • [claimed-docs] “This guide walks you through finding a failed run, pulling its trace, and identifying which step broke. You do this entirely from the termin…”
   • [probe] “official CLI documented at https://www.inngest.com/docs/cli”

   proof ↗⚑ flag

   Hatchet✓fullprobed8/10

   Hatchet ships an official CLI documented with multiple subcommands (worker dev, tui, quickstart, profile) for local dev, observability, scaffolding, and environment management, confirmed by docs and a dedicated CLI reference page. Missing for 10: independent hands-on community review specifically of the CLI's agentic/AI-native workflows and broader third-party validation beyond docs.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “the `hatchet quickstart` command generates a worker project from a template to help you get started quickly”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [probe] “official CLI documented at https://docs.hatchet.run/reference/cli”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to Inngest
   Inngest✓fullprobed8/10

   Inngest publishes a documented REST API (api-docs.inngest.com) covering events, function runs, and environments, plus a CLI and MCP server for programmatic/agent-driven operation, and an llms.txt for AI-native discovery. Missing for 10: a public OpenAPI spec was not found (probe returned 404s) and no independent third-party corroboration of API usage exists.

   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.inngest.com/llms.txt # Inngest > Inngest is the durable workflow engine for AI applications. It pro…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.inngest.com/openapi.json, https://www.inngest.com/swagger.json, https://www.inngest.com/…”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”
   • [probe] “official CLI documented at https://www.inngest.com/docs/cli”

   proof ↗⚑ flag

   Hatchet~partialprobed6/10

   Hatchet documents multi-language SDKs (Python, TypeScript, Go, Ruby) with detailed API surfaces (retry policies, cron, concurrency, rate limits, webhooks, OpenTelemetry, embedded mode) and a CLI, giving AI-native users multiple documented ways to drive the product programmatically, including MCP/agent-tool integrations. However, a probe for a standard public REST/OpenAPI spec returned 404s across all expected paths, suggesting no first-class REST API doc is discoverable, only SDK/CLI-level docs. Missing for 10: a discoverable OpenAPI/REST API reference, and independent hands-on confirmation that the documented API surface is complete/accurate.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Concurrency”
   • [claimed-docs] “Rate Limits”
   • [claimed-docs] “Webhooks”
   • [claimed-docs] “OpenTelemetry”
   • [claimed-docs] “Embedded Mode”
   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [probe] “official CLI documented at https://docs.hatchet.run/reference/cli”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Inngest—none0/10

   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.

   ⚑ flag

   Hatchet—none0/10

   No evidence of scoped or least-privilege API credential/token issuance for agents — the pack covers CLI tooling, concurrency, self-hosting, and pricing tiers (SSO/audit logs) but never describes API key scoping or credential minimization features.

   ⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Inngest✓fullprobed8/10

   Inngest ships official SDKs for TypeScript, Python, and Go with full documentation for building durable functions, agent workflows (AgentKit), step orchestration, and AI-specific tooling (step.ai.wrap, durable agents, agent evals), plus a REST API and CLI for programmatic access — directly supporting AI-native builders. Community feedback corroborates good developer experience building against the SDKs in production. Missing for 10: independent third-party benchmarking of SDK completeness/quality across all three languages and a public OpenAPI spec (probe found 404s).

   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”
   • [claimed-docs] “AgentKit is a framework to build AI Agents, from single model inference calls to multi-agent systems that use tools.”
   • [claimed-docs] “Every step, every tool call, every decision the agent makes is checkpointed as it happens. If the process dies at step 7 of 12, the agent pi…”
   • [claimed-docs] “step.ai.wrap() wraps other AI SDKs (OpenAI, Anthropic, and Vercel AI SDK) as a step, augmenting the observability of your Inngest Functions …”
   • [claimed-docs] “This guide walks you through building a ReAct-style agent loop (Reason → Act → Observe → Repeat) where each iteration is a durable, retriabl…”
   • [claimed-docs] “Delegation gives sub-agents their own context window, tools, and token budget. A sub-agent can be modeled as a separate Inngest function tha…”
   • [claimed-docs] “Agent Evals help you measure how well AI agents and workflows perform in production. You attach scores to function runs, group related work …”
   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”
   • [community] “Congrats! I used Inngest when I wrote a video processing pipeline... Amazing devEx. Thanks so much for all the work and enabling a local mod…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.inngest.com/openapi.json, https://www.inngest.com/swagger.json, https://www.inngest.com/…”

   proof ↗⚑ flag

   Hatchet✓fullcommunity8/10

   Hatchet ships official SDKs for Python, TypeScript, Go, and Ruby, confirmed both in docs and independently by community members who verified multi-language SDK support, and these SDKs are the basis for building AI agent workflows (including cookbooks integrating Claude Agent SDK and OpenAI Agents SDK). missing for 10: no independent quality/maturity comparison across SDKs and a community complaint that SDK/doc specs are sometimes incomplete or have broken links.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [community] “This looks very cool! I see a lot of Python in the docs; is it usable in other languages? [confirmed SDKs exist for Python, Typescript and G…”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [community] “Why not fix all the broken doc links and make sure you have the full sdk spec down first, ready to go? ... this came off as extremely unprof…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Inngest
   Inngest✓fullclaimed8/10

   Inngest explicitly documents creating unique webhook consumer URLs for any third-party service (e.g. Stripe, Github, Clerk), which act as event sources triggering functions/agents, directly matching the story of subscribing to events via webhooks. This is well-documented first-party capability, though missing for 10: independent hands-on verification of webhook subscription specifically (community evidence covers other features, not webhooks directly).

   • [claimed-docs] “Inngest enables you to create any number of unique URLs which act as webhook consumers. You can create a webhook for each third party servic…”
   • [claimed-docs] “Inngest enables you to create any number of unique URLs which act as webhook consumers. You can create a webhook for each third party servic…”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   There is a dedicated docs page titled "Webhooks" indicating Hatchet supports webhook functionality, but no detail is given on whether this covers subscribing to Hatchet's own workflow/task events (vs. using webhooks as workflow triggers), and no independent confirmation of this specific direction. missing for 10: description of webhook event subscription semantics, example payloads/config, and community/hands-on confirmation of outbound event webhooks.

   • [claimed-docs] “Webhooks”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Inngest
   Inngest✓fullcommunity9/10

   Inngest is built specifically for durable, autonomous background execution: scheduled/cron functions, event-triggered functions, durable steps with automatic retries and checkpointing, wait-for-event/human-in-loop pausing, and dedicated durable-agent patterns (agent loops, sub-agent delegation) that resume execution exactly where they left off after failures or long waits. Community reviews corroborate reliable use for background job/video-processing pipelines running unattended for months. Missing for 10: no independent third-party benchmark of a fully unsupervised long-running AI agent in production beyond vendor docs and general background-job testimonials.

   • [claimed-docs] “Inngest's cron schedules also support timezones, allowing you to schedule work in whatever timezone you need work to run in.”
   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “Every step, every tool call, every decision the agent makes is checkpointed as it happens. If the process dies at step 7 of 12, the agent pi…”
   • [claimed-docs] “If the process dies at step 7 of 12, the agent picks up at step 7 — not step 1. If the agent needs to wait three hours for a human to approv…”
   • [claimed-docs] “Use step.waitForEvent() to pause agent execution for human approval, then resume or abort based on the response.”
   • [claimed-docs] “Delegation gives sub-agents their own context window, tools, and token budget. A sub-agent can be modeled as a separate Inngest function tha…”
   • [claimed-docs] “By default, in addition to the initial attempt, Inngest will retry a function or a step up to 4 times until it succeeds.”
   • [community] “I implemented Inngest to handle our video migration queues... complete breeze. Loved the balance between the amount of complexity that's abs…”
   • [community] “With Inngest, I moved all of our background services and processing to a separate sub-repo, and we can develop, deploy and monitor entirely …”

   proof ↗⚑ flag

   Hatchet✓fullcommunity8/10

   Hatchet is fundamentally a background task/workflow orchestration engine with cron triggers, scheduled runs, durable retries, concurrency control, and explicit support for orchestrating AI agents autonomously (docs-16, docs-26, docs-27, docs-25, docs-11, gh-2, gh-3), and community evidence confirms real production use as a background job/workflow runner replacing Celery. Cookbooks show integration with Claude/OpenAI Agents SDKs for agentic workflows (hatchet-docs-34/36/37). missing for 10: no independent hands-on account of a fully autonomous multi-day agent running unattended, and some community reports note scaling/reliability caveats under heavy load (hatchet-comm-11) rather than confirming flawless long-running autonomy.

   • [claimed-docs] “A single platform for orchestrating AI agents, scheduling background tasks, and running mission-critical workflows”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [github] “An orchestration engine for background tasks, AI agents, and durable workflows”
   • [community] “Looks pretty great! My biggest issue with Celery has been that the observability is pretty bad. Even if you use Celery Flower, it still just…”
   • [community] “Great job so far- The flow-based UI with triggers is killer! AFAIK, this surpasses what Celery includes.”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Inngest
   Inngest~partialprobed6/10

   Inngest ships an official MCP server so natural-language coding agents (Claude Code, Codex, Cursor) can inspect and operate the platform, and its CLI is documented as agent-accessible for run inspection/invocation — enabling NL-driven operation indirectly through third-party AI clients rather than a built-in NL command interface. Missing for 10: a first-party chat/NL interface within Inngest itself, and independent hands-on evidence of the MCP server actually being used to operate Inngest via natural language.

   • [claimed-docs] “Connect Claude Code, Codex, Cursor, or another MCP client to inspect and operate Inngest from your coding agent.”
   • [probe] “official MCP server documented at https://www.inngest.com/docs/ai-dev-tools/mcp”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”
   • [probe] “official CLI documented at https://www.inngest.com/docs/cli”

   proof ↗⚑ flag

   Hatchet—none0/10

   Hatchet's evidence shows a structured CLI, TUI, and API/SDKs, plus the ability to expose Hatchet workflows as tools *for* external AI agents (Claude Agent SDK, OpenAI Agents SDK) — but nothing shows a user operating Hatchet itself via natural-language commands (e.g., a chat interface or NL-to-command translation). The MCP/agent-tools integration is about agents consuming Hatchet, not about a human issuing NL commands to Hatchet.

   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [probe] “official CLI documented at https://docs.hatchet.run/reference/cli”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Inngest—none0/10

   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.

   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.inngest.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.inngest.com/openapi.json, https://www.inngest.com/swagger.json, https://www.inngest.com/…”

   proof ↗⚑ flag

   Hatchet—none0/10

   No evidence of an interactive API reference or runnable-example explorer; probes for OpenAPI/Swagger endpoints returned 404s and docs only reference CLI/SDK references and cookbooks, not an interactive API console.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.hatchet.run/llms.txt # Hatchet Documentation > Hatchet is a distributed task queue and workflow en…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Inngest—none0/10

   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.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.inngest.com/openapi.json, https://www.inngest.com/swagger.json, https://www.inngest.com/…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.inngest.com/docs.md”
   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”

   proof ↗⚑ flag

   Hatchet—none0/10

   A direct probe for OpenAPI/swagger spec files at all standard locations returned 404s, and no evidence pack item points to a downloadable API spec; Hatchet does expose an llms.txt but that is not a machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.hatchet.run/llms.txt # Hatchet Documentation > Hatchet is a distributed task queue and workflow en…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Inngest
   Inngest~partialcommunity5/10

   Inngest provides a local/dev server and Jest-compatible testing utilities (inngest-docs-14) plus community reports of a 'local mode'/development server that eases debugging without touching production (inngest-comm-7, inngest-comm-9), and REST API/self-hosting docs reference distinct 'environments' (inngest-docs-7, inngest-docs-9). However there is no first-party documentation explicitly describing a dedicated sandbox/staging environment isolated from production data. Missing for 10: explicit docs on environment isolation/branching for safe testing, and independent verification that dev-server tests never touch production data.

   • [claimed-docs] “This allows you to mock function state, step tooling, and inputs with a Jest-compatible API supporting all major testing frameworks, runtime…”
   • [community] “Congrats! I used Inngest when I wrote a video processing pipeline... Amazing devEx. Thanks so much for all the work and enabling a local mod…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”
   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “While the easiest way to get started with Inngest is using our hosted platform... we understand that developers may want to self-host for a …”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet supports local development via `hatchet worker dev` for local execution and `hatchet profile` for switching between separate named environments/tenants, which could be used to isolate a sandbox from production, but there is no explicit documentation of a dedicated sandbox/staging environment or test-data isolation feature. missing for 10: explicit sandbox/test-environment documentation, isolation guarantees between environments, and any hands-on confirmation that switching profiles avoids touching production data.

   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected.”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [claimed-docs] “Running Workers Locally”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Inngest—none0/10

   While Inngest exposes a REST API (inngest-docs-7) and SDK version paths (e.g. /v4/ in inngest-docs-14), the evidence pack contains no documented API versioning scheme or deprecation policy; the closest doc (inngest-docs-19) actually describes avoiding explicit version markers for function changes, not an API deprecation policy. No changelog, migration guide, or deprecation timeline is evidenced.

   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “Inngest enables developers to deploy changes to functions without explicit version markers or complex migration logic.”
   • [claimed-docs] “This allows you to mock function state, step tooling, and inputs with a Jest-compatible API supporting all major testing frameworks, runtime…”

   proof ↗⚑ flag

   Hatchet—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; the OpenAPI spec probe returned 404s and no changelog/deprecation policy content is present, only a v1 docs path exists without explanation of versioning/deprecation guarantees.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [claimed-docs] “Retry Policies”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Hatchet
   Inngest~partialclaimed4/10

   Inngest is a workflow/event orchestration engine, not a data-record management tool, so 'bulk operations across many items' isn't a native concept, but its event-driven fan-out (events trigger many function runs), concurrency keys, and REST API could plausibly support batch-style processing across many items. There's no explicit documentation of a bulk-operation API, batch invoke, or multi-item selection/action feature. missing for 10: explicit bulk/batch operation API or UI, evidence of processing many items in a single user-triggered action, and independent confirmation of bulk-scale usage patterns.

   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”
   • [claimed-docs] “Inngest enables you to create any number of unique URLs which act as webhook consumers. You can create a webhook for each third party servic…”

   proof ↗⚑ flag

   Hatchet~partialclaimed5/10

   Hatchet is a workflow/task orchestration engine that supports bulk-style operations via concurrency rules across many workflow runs, cron-triggered batch scheduling, and per-key concurrency limits (e.g., letting many tasks/workflows run concurrently up to a limit), which indirectly supports bulk processing of many items. However, there is no explicit evidence of a bulk API/CLI operation (e.g., bulk-cancel, bulk-retry, batch-trigger-many-runs-at-once) designed for an AI-native user to invoke as a single bulk action. missing for 10: explicit bulk-operation API/CLI (batch trigger, bulk cancel/retry across many runs), documentation or examples showing an AI agent invoking such bulk operations, and independent confirmation of bulk operation reliability at scale.

   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Inngest
   Inngest✓fullcommunity8/10

   Inngest is fundamentally an event-driven automation engine: functions are triggered by events, cron schedules, or waits, and can pause/resume on incoming events (step.waitForEvent), webhooks act as event sources, and rate limiting/concurrency rules govern execution — directly matching 'rules that trigger actions on events'. Community reports corroborate reliable production use of these event/trigger workflows. Missing for 10: no independent benchmark of complex rule-conditioning logic (e.g. multi-condition rule matching beyond simple event names/waits) and no evidence of a declarative 'if X and Y then trigger Z' rule builder beyond code-based triggers.

   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”
   • [claimed-docs] “Inngest enables you to create any number of unique URLs which act as webhook consumers. You can create a webhook for each third party servic…”
   • [claimed-docs] “Inngest's cron schedules also support timezones, allowing you to schedule work in whatever timezone you need work to run in.”
   • [claimed-docs] “Rate limiting is a hard limit on how many function runs can start within a time period. Events that exceed the rate limit are skipped and do…”
   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [community] “Really great product, I'm using inngest since 2-3 months and it definitely solved our problem. We needed a scheduling, queue, trigger soluti…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed7/10

   Hatchet's docs describe core event-driven automation: workflows can be triggered on schedules (cron, scheduled runs), via webhooks, and filtered/gated with CEL-based event filters and concurrency rules, all managed by a control plane that automatically dispatches tasks to workers on these triggers. This directly matches 'define rules that trigger actions automatically on events' for an orchestration/automation platform. Missing for 10: explicit first-party documentation of arbitrary custom event triggers (e.g., pub/sub event names beyond cron/webhook) and independent hands-on confirmation that event-triggered rules work reliably in production.

   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Webhooks”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”
   • [claimed-docs] “Concurrency”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Inngest
   Inngest✓fullcommunity9/10

   Inngest explicitly supports cron-based scheduled functions with timezone support (inngest-docs-17/31) plus recurring/triggered workflows via durable steps, retries, and wait-for-event orchestration (inngest-docs-2, -18, -32), and community reports confirm real-world use for scheduling/queueing needs (inngest-comm-1). missing for 10: independent hands-on verification specifically of recurring cron scheduling (most community evidence is about general job/queue use, not cron recurrence specifically).

   • [claimed-docs] “Inngest's cron schedules also support timezones, allowing you to schedule work in whatever timezone you need work to run in.”
   • [claimed-docs] “You can create scheduled functions that run in any timezone using the SDK's createFunction()”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”
   • [community] “Really great product, I'm using inngest since 2-3 months and it definitely solved our problem. We needed a scheduling, queue, trigger soluti…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Hatchet explicitly documents Cron Runs and Scheduled Runs as first-class workflow trigger types, alongside concurrency/rate-limit controls, giving clear support for scheduling recurring jobs/workflows (hatchet-docs-16, hatchet-docs-26, hatchet-docs-27). This is corroborated by the general orchestration platform framing in GitHub docs and self-hosting control plane description. Missing for 10: independent/hands-on community confirmation specifically of cron/scheduled run reliability at scale, and more detail on failure/edge-case handling for recurring jobs.

   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Inngest
   Inngest~partialclaimed4/10

   Inngest supports versionless function deployment (docs-19) and observability/tracing/debugging via CLI (docs-37, docs-20) which give some ability to inspect and review automation runs, but there is no evidence of explicit version history, diffing, approval workflows, or a rollback mechanism for automations/functions themselves. missing for 10: explicit version control/history for functions, a documented rollback capability, review/approval workflow for changes to automations, and independent confirmation of these features.

   • [claimed-docs] “Inngest enables developers to deploy changes to functions without explicit version markers or complex migration logic.”
   • [claimed-docs] “Inngest captures execution data for every function run. You get metrics, traces, event logs, and per-step timing without instrumenting your …”
   • [claimed-docs] “This guide walks you through finding a failed run, pulling its trace, and identifying which step broke. You do this entirely from the termin…”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”

   proof ↗⚑ flag

   Hatchet—none0/10

   No evidence in the pack describes versioning, review, or rollback of workflows/automations — the docs cover CLI tools, concurrency, retries, cron/scheduled runs, and self-hosting, but nothing about workflow version history, diff/review workflows, or rollback to a prior version. This is a fair axis for a workflow orchestration platform, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

Local dev

1. backend developerOne command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps

   weight 2 · round to Inngest
   Inngest~partialcommunity6/10

   Inngest documents a local dev server run via CLI (community confirms 'enabling a local mode' and a 'development server' that 'makes debugging jobs very easy'), and a Jest-compatible testing API for mocking function state, step tooling, and inputs. However, there is no explicit evidence of time-skipping/time-travel test utilities, and the 'one command runs the whole engine' claim is only indirectly evidenced via CLI docs and community mentions rather than a dedicated doc citation. missing for 10: explicit single-command local engine startup docs, explicit time-skipping/clock-mocking test utility documentation, independent hands-on confirmation of the testing API itself.

   • [claimed-docs] “This allows you to mock function state, step tooling, and inputs with a Jest-compatible API supporting all major testing frameworks, runtime…”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”
   • [community] “Congrats! I used Inngest when I wrote a video processing pipeline... Amazing devEx. Thanks so much for all the work and enabling a local mod…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   Docs show `hatchet worker dev` for running a worker locally with auto-reload and mention an 'Embedded Mode' page, which partially supports a lightweight local run, but there is no evidence of a single command spinning up the full engine (control plane) locally, nor any documented unit-testing utilities, time-skipping, or step mocking for workflows. Missing for 10: dedicated single-command full-engine local runner, workflow unit-testing framework, time-skipping/mocked-step utilities, and any independent confirmation of these testing features.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected.”
   • [claimed-docs] “Embedded Mode”
   • [claimed-docs] “Running Workers Locally”

   proof ↗⚑ flag

Approvals

1. backend developerA workflow pauses for human approval or input for hours or days and resumes the moment the response arrives

   weight 3 · round to Inngest
   Inngest✓fullclaimed9/10

   Inngest's step.waitForEvent() explicitly pauses a function run until a matching event is received, with no polling or held resources, and docs specifically describe waiting hours/days for human approval before resuming exactly where it left off (e.g. 'wait three hours for a human to approve something, it suspends entirely, holding zero resources, and resumes when the approval arrives'), plus a dedicated human-in-the-loop pattern guide. Missing for 10: independent/hands-on community verification specifically of long-duration human-approval waits (community evidence covers general reliability but not this exact scenario).

   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”
   • [claimed-docs] “If the process dies at step 7 of 12, the agent picks up at step 7 — not step 1. If the agent needs to wait three hours for a human to approv…”
   • [claimed-docs] “Use step.waitForEvent() to pause agent execution for human approval, then resume or abort based on the response.”
   • [claimed-docs] “Every step, every tool call, every decision the agent makes is checkpointed as it happens. If the process dies at step 7 of 12, the agent pi…”

   proof ↗⚑ flag

   Hatchet—none0/10

   No evidence describes a durable pause/resume mechanism for human approval or external event input (e.g., a wait-for-event or signal API); the pack covers retries, cron, scheduling, concurrency, webhooks, and AI-agent tool integrations but never a human-in-the-loop pause/resume pattern.

   ⚑ flag

Signals

1. backend developerI send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow

   weight 2 · round to Inngest
   Inngest✓fullclaimed9/10

   Inngest explicitly supports sending events into a running workflow via step.waitForEvent() to pause and resume based on an external event, with documented human-in-the-loop patterns (waiting for approval), plus REST API and webhook consumers to inject events from external sources like APIs or third-party services, and event/invoke propagation across child runs. missing for 10: independent hands-on confirmation specifically of the waitForEvent/signal pattern (community evidence is about general reliability, not this specific capability).

   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”
   • [claimed-docs] “Use step.waitForEvent() to pause agent execution for human approval, then resume or abort based on the response.”
   • [claimed-docs] “If the process dies at step 7 of 12, the agent picks up at step 7 — not step 1. If the agent needs to wait three hours for a human to approv…”
   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “Inngest enables you to create any number of unique URLs which act as webhook consumers. You can create a webhook for each third party servic…”
   • [claimed-docs] “Sessions now propagate to child runs. Any run triggered by another run (via event, invoke, or defer) inherits its parent's sessions.”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   Docs reference 'Webhooks' and CEL-based 'event filters' for triggering workflows externally, implying some external event-to-workflow capability, but there is no concrete documentation of sending a signal/event into a specific *already-running* workflow instance (e.g., a signal API) as opposed to triggering new runs. Missing for 10: explicit signal-to-running-workflow API docs, examples of external systems pushing data into an in-flight workflow, and independent confirmation this works in practice.

   • [claimed-docs] “Webhooks”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”

   proof ↗⚑ flag

Metrics

1. platform engineerFailure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave

   weight 1 · round to Inngest
   Inngest~partialclaimed5/10

   Inngest documents built-in observability — metrics, traces, event logs, and per-step timing captured automatically for every run (docs-20), and OpenTelemetry-derived gen_ai.* metadata is surfaced in an AI Overview dashboard (docs-3/27). This shows internal capture and some OTel-based data, but there's no documented mechanism for exporting these metrics/traces to an external observability stack (Prometheus, Datadog, Grafana) or for configuring alerts that fire on failure rates, latency thresholds, or queue depth anomalies. missing for 10: explicit metrics/traces export integration to third-party observability platforms, native alerting/alert-rule configuration for failure or latency thresholds, queue-depth metric documentation.

   • [claimed-docs] “Inngest captures execution data for every function run. You get metrics, traces, event logs, and per-step timing without instrumenting your …”
   • [claimed-docs] “We've added AI Overview, a dashboard that turns the OpenTelemetry-derived gen_ai.* metadata Inngest already captures from your AI calls into…”
   • [claimed-docs] “We've added AI Overview, a dashboard that turns the OpenTelemetry-derived `gen_ai.*` metadata Inngest already captures from your AI calls in…”
   • [claimed-docs] “step.ai.wrap() wraps other AI SDKs (OpenAI, Anthropic, and Vercel AI SDK) as a step, augmenting the observability of your Inngest Functions …”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet documents an OpenTelemetry integration page and its GitHub README claims 'real-time monitoring, alerting, and logging' as part of the platform, plus a TUI for real-time observability into tasks/workflows/workers. However, there is no concrete detail on which metrics (failure rates, latencies, queue depths) are exported, no evidence of alert rule configuration, and no independent confirmation that alerting actually fires as described. Missing for 10: detailed OpenTelemetry metrics/export documentation, explicit failure-rate/latency/queue-depth metric definitions, documented alerting configuration/integration with observability stacks (Grafana/Datadog/PagerDuty), and hands-on or community confirmation that alerts work in practice.

   • [claimed-docs] “OpenTelemetry”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”

   proof ↗⚑ flag

Replay

1. platform engineerI replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover

   weight 2 · round to Inngest
   Inngest~partialclaimed5/10

   Inngest documents automatic retries and step-level checkpointing that let a function resume from the last successful step (inngest-docs-2, inngest-docs-15), plus CLI/dashboard tooling for finding a failed run, pulling its trace, and identifying the broken step (inngest-docs-37, inngest-docs-20). However, this covers automatic retry/resume and diagnosis, not an explicit manual 'replay/rerun from history, optionally from a chosen step' action initiated by an operator. Missing for 10: explicit documentation of a manual replay/rerun feature (e.g., a dashboard 'rerun' button or API endpoint) that lets an engineer restart a completed/failed run from an arbitrary recorded step, and independent confirmation it works as described.

   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “By default, in addition to the initial attempt, Inngest will retry a function or a step up to 4 times until it succeeds.”
   • [claimed-docs] “Inngest captures execution data for every function run. You get metrics, traces, event logs, and per-step timing without instrumenting your …”
   • [claimed-docs] “This guide walks you through finding a failed run, pulling its trace, and identifying which step broke. You do this entirely from the termin…”

   proof ↗⚑ flag

   Hatchet—none0/10

   The evidence pack covers retries, concurrency, scheduling, and TUI-based observability, but nothing describes replaying or rerunning a failed workflow from recorded history, let alone from a specific step. Retry Policies (hatchet-docs-25) is only a title with no detail confirming step-level replay/rerun-from-history semantics.

   ⚑ flag

Run visibility

1. platform engineerEvery run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter

   weight 3 · round to Inngest
   Inngest✓fullcommunity8/10

   Docs describe capturing metrics, traces, event logs, and per-step timing for every run without instrumentation, plus a CLI workflow for finding a failed run, pulling its trace, and identifying which step broke — matching the searchable, filterable step-by-step timeline story. Community feedback corroborates the dev/monitoring experience (local dev server, easy debugging) as reliable in practice. Missing for 10: explicit documentation of dashboard search/filter UI mechanics (e.g., filter by input/output values) and independent hands-on screenshots of the dashboard timeline itself.

   • [claimed-docs] “Inngest captures execution data for every function run. You get metrics, traces, event logs, and per-step timing without instrumenting your …”
   • [claimed-docs] “This guide walks you through finding a failed run, pulling its trace, and identifying which step broke. You do this entirely from the termin…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”

   proof ↗⚑ flag

   Hatchet~partialcommunity5/10

   Hatchet's docs and GitHub description claim 'real-time monitoring, alerting, and logging' and a TUI/dashboard for observability into tasks and workflows, and community feedback confirms a 'flow-based UI' seen as an improvement over Celery's observability. However, no evidence explicitly describes a searchable/filterable dashboard showing per-step inputs, outputs, retries, and errors in a timeline view — retry policies and OpenTelemetry integration are documented separately but not tied to a unified searchable timeline UI. Missing for 10: explicit documentation or screenshots of a step-level timeline view, confirmation of search/filter capability in the dashboard, and independent hands-on verification of this specific UI feature.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “OpenTelemetry”
   • [community] “Looks pretty great! My biggest issue with Celery has been that the observability is pretty bad. Even if you use Celery Flower, it still just…”
   • [community] “Great job so far- The flow-based UI with triggers is killer! AFAIK, this surpasses what Celery includes.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Inngest~partialprobed5/10

   Inngest ships a documented REST API (events, function runs, environments) and a CLI that can inspect runs, fetch traces, and invoke functions, giving reasonable programmatic coverage of core operational tasks. However, there's no evidence of an OpenAPI spec (docs.md and openapi.json probes both 404) and no explicit claim that UI-only surfaces like AI Overview or Agent Evals dashboards are fully API-accessible, so full UI/API parity is unconfirmed. Missing for 10: OpenAPI/spec discoverability, explicit parity statement covering dashboard-specific features (AI Overview, Agent Evals, session management), and independent confirmation that API can replicate every UI action.

   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “Inspect runs, fetch traces, invoke functions, and give coding agents access to your Inngest data from the terminal.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.inngest.com/openapi.json, https://www.inngest.com/swagger.json, https://www.inngest.com/…”
   • [claimed-docs] “We've added AI Overview, a dashboard that turns the OpenTelemetry-derived gen_ai.* metadata Inngest already captures from your AI calls into…”
   • [claimed-docs] “Agent Evals help you measure how well AI agents and workflows perform in production. You attach scores to function runs, group related work …”

   proof ↗⚑ flag

   Hatchet~partialprobed5/10

   Hatchet offers SDKs (Python/TS/Go/Ruby) and CLI tools for managing workflows, tasks, cron, concurrency, etc., implying broad API-driven access, but there is no explicit documentation or OpenAPI spec confirming full parity between API/SDK capabilities and the web UI, and the openapi probe returned 404s. missing for 10: a published OpenAPI/API reference confirming API parity, explicit statement or evidence that every UI action (e.g., dashboards, tenant/user management, alerting config) is achievable via API/SDK, and independent confirmation of this parity.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [community] “This looks very cool! I see a lot of Python in the docs; is it usable in other languages? [confirmed SDKs exist for Python, Typescript and G…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Inngest~partialcommunity4/10

   Inngest offers self-hosting (own your infra/data) and a REST API to programmatically pull events, runs, and traces, which gives some data portability, but there is no documented bulk 'export all data' feature or explicit open-format export tool, and the platform's license is Source Available/SSPL rather than fully open, which the community flags as limiting true openness. missing for 10: explicit bulk data-export feature, documented open-format export tool, and independent confirmation that self-hosted/API data covers 100% of stored history.

   • [claimed-docs] “The Inngest REST API lets you interact with events, function runs, environments, and more programmatically.”
   • [claimed-docs] “While the easiest way to get started with Inngest is using our hosted platform... we understand that developers may want to self-host for a …”
   • [claimed-docs] “Self-hosting support for Inngest is supported as of the 1.0 release.”
   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”
   • [community] “Looking at the License - This is not Open Source, but rather Source Available software. Looks great but do not appreciate deceptive marketin…”
   • [community] “Can you elaborate on why you chose to go with SSPL license? ... OSI stating that the SSPL does not comply with its Open Source Definition, d…”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet is open-source and self-hostable, meaning users control their own Postgres-backed control plane and inherently retain access to underlying data (hatchet-docs-8, hatchet-docs-17, hatchet-docs-23), which supports an exit path. However, there is no explicit documented data-export feature, open-format export tooling, or migration/export API mentioned anywhere in the evidence. Missing for 10: explicit data export command/API, documentation on open-format export (e.g. JSON/CSV dumps), and independent confirmation that a full data export is possible beyond raw DB access.

   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Run Hatchet yourself”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Hatchet
   Inngest!disputedcontradicted3/10

   Inngest's source is publicly viewable on GitHub (inngest-gh-1), but community evidence explicitly states the license (SSPL) is not OSI-approved open source, calling it 'source available' and 'fauxpen source' rather than truly open licensed (inngest-comm-2, inngest-comm-11, inngest-comm-12). Missing for 10: an actual OSI-approved open-source license, first-party confirmation of licensing terms, and any docs evidence rebutting the community's characterization.

   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”
   • [community] “Looking at the License - This is not Open Source, but rather Source Available software. Looks great but do not appreciate deceptive marketin…”
   • [community] “Can you elaborate on why you chose to go with SSPL license? ... OSI stating that the SSPL does not comply with its Open Source Definition, d…”
   • [community] “SSPL license noted for Inngest's open-source event-driven queue CLI, raising licensing concerns among commenters.”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   The product's source is publicly hosted on GitHub (hatchet-dev/hatchet), which lets users read the code, but the evidence pack never states or documents an explicit open-source license (e.g., MIT/Apache) for that repository. missing for 10: explicit license text/badge, license file reference, confirmation the full engine (not just SDKs) is open-licensed.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [github] “An orchestration engine for background tasks, AI agents, and durable workflows”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Hatchet
   Inngest✓fullcommunity7/10

   Inngest documents self-hosting as officially supported since its 1.0 release, with GitHub confirming you can deploy functions to your own infrastructure and sync with a self-hosted Inngest server. Community discussion notes the project uses a source-available (SSPL) license rather than pure open source, which tempers the 'openness' framing even though self-hosting itself is functional and documented. Missing for 10: independent hands-on report of running the self-hosted server successfully, and clarity on feature parity between self-hosted and cloud versions.

   • [claimed-docs] “While the easiest way to get started with Inngest is using our hosted platform... we understand that developers may want to self-host for a …”
   • [claimed-docs] “Self-hosting support for Inngest is supported as of the 1.0 release.”
   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”
   • [community] “Looking at the License - This is not Open Source, but rather Source Available software. Looks great but do not appreciate deceptive marketin…”
   • [community] “Can you elaborate on why you chose to go with SSPL license? ... OSI stating that the SSPL does not comply with its Open Source Definition, d…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Hatchet has dedicated self-hosting docs explicitly stating you can run your own Hatchet Control Plane instance, with a full self-hosting guide and 'Run Hatchet yourself' section, and is open-source on GitHub. Missing for 10: independent hands-on confirmation of a successful self-hosted deployment (community discussion focuses on managed/product feedback rather than self-host experience) and more detail on infra requirements/HA in self-hosted mode.

   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Run Hatchet yourself”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

Deployment model

1. platform engineerI run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network

   weight 2 · round to Inngest
   Inngest✓fullclaimed7/10

   Inngest's core architecture explicitly separates execution (your functions run on your own infra/servers) from the managed control plane: 'Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform' (inngest-gh-1), and self-hosting is documented as a supported option since 1.0 (inngest-docs-9, inngest-docs-28) alongside encryption middleware for extra data control (inngest-docs-10). This matches the platform-engineer story of workers-in-your-network with vendor-managed orchestration. Missing for 10: independent/hands-on verification of data-residency guarantees in the hybrid (non-fully-self-hosted) mode, and more detail on network isolation/security posture of the control-plane-to-worker connection.

   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”
   • [claimed-docs] “While the easiest way to get started with Inngest is using our hosted platform... we understand that developers may want to self-host for a …”
   • [claimed-docs] “Self-hosting support for Inngest is supported as of the 1.0 release.”
   • [claimed-docs] “For an added layer of encryption and control of your data, install encryption middleware and bring your own encryption key.”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet's architecture separates a 'worker' component (run via `hatchet worker dev`) from a central control plane, and `hatchet profile` lets you connect a local worker to different named Hatchet instances/tenants, which is consistent with running workers in your own infra against a vendor-hosted control plane; pricing tiers also imply a hosted/Cloud offering distinct from self-hosting. However, the evidence never explicitly states that when using the hosted (Cloud) control plane, task code/data stays inside the customer's network — the only explicit control-plane documentation describes full self-hosting (running your own control plane), not the hybrid vendor-managed-plane/self-hosted-worker model the story describes. Missing for 10: explicit vendor statement or docs describing the hybrid 'Cloud control plane + self-hosted workers, data stays in your network' architecture, and any data-residency/security claims tied to that specific topology.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Get up and running in minutes. When you’re ready to scale, upgrade anytime and only pay for what you use.”
   • [claimed-docs] “Running Workers Locally”

   proof ↗⚑ flag

Flow control

1. platform engineerI cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest

   weight 2 · round drawn
   Inngest✓fullclaimed8/10

   Docs explicitly support per-key concurrency limits (e.g., per user id) via step concurrency keys, and separate hard rate-limiting on function runs within a time period, directly enabling per-tenant/per-key throttling to prevent one hot customer from starving others. Missing for 10: no independent/hands-on evidence validating multi-tenant fairness at scale, and no explicit combined example of concurrency+rate-limit used together per tenant in production.

   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [claimed-docs] “Rate limiting is a hard limit on how many function runs can start within a time period. Events that exceed the rate limit are skipped and do…”
   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Docs explicitly cover per-key concurrency limits via CEL expressions (e.g., premium vs standard tiers), shared concurrency rules across workflows per user, configurable queue-depth strategies (CANCEL_QUEUED_EXCEPT_NEWEST/OLDEST), and a dedicated Rate Limits reference page alongside a Concurrency reference page, directly matching the per-workflow/per-key/per-tenant throttling story. missing for 10: no independent/hands-on validation of rate-limit or per-tenant isolation behavior under real load, and no explicit doc example scoping limits strictly 'per tenant' as opposed to per-key/user.

   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “Concurrency”
   • [claimed-docs] “Rate Limits”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”

   proof ↗⚑ flag

Prioritization

1. platform engineerI assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue

   weight 1 · round to Hatchet
   Inngest~partialclaimed3/10

   Inngest documents concurrency limiting with per-key scoping (e.g., per user id) and rate limiting, which can approximate fair resource allocation across tenants, but there is no evidence of an explicit run-priority mechanism or documentation describing 'fair scheduling' across tenants as such. Missing for 10: explicit priority assignment API/config for runs, documentation of a fairness/anti-starvation scheduling algorithm across tenants, and any benchmark or hands-on evidence showing priority-based scheduling in practice.

   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [claimed-docs] “Rate limiting is a hard limit on how many function runs can start within a time period. Events that exceed the rate limit are skipped and do…”
   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet documents per-key concurrency limits driven by CEL expressions that can differentiate tenants/tiers (e.g., premium users get 10 concurrent runs vs 1 for others) and multiple concurrency strategies, which gives some tenant-level fairness/resource allocation. However, there is no documented 'priority' field or priority-based scheduler for runs, nor explicit anti-starvation FIFO-replacement mechanism — the evidence only covers concurrency caps, not priority assignment. Missing for 10: explicit run/task priority attribute, priority-aware scheduler documentation, and independent confirmation that concurrency limits actually produce fair scheduling across tenants under load.

   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “Concurrency”

   proof ↗⚑ flag

Scaling

1. platform engineerThroughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss

   weight 2 · round to Hatchet
   Inngest~partialclaimed5/10

   Inngest's docs describe a serverless model where the platform handles queueing, scaling, and concurrency without users managing workers (docs-1, docs-24), and step-level checkpointing/retries (docs-2, docs-15, docs-21) imply resilience if an executing process dies. Self-hosted mode also supports syncing functions across your own infra (inngest-gh-1), suggesting a worker-fleet model. However, no evidence explicitly documents load-balancing algorithms across a worker fleet or explicit fault-tolerance to worker-node loss (as opposed to step/function-level retries), and no community reports confirm this at scale. Missing for 10: explicit load-balancing/fleet-distribution docs, documented behavior when a worker node goes down mid-execution, and independent benchmarks/community confirmation of horizontal scaling behavior.

   • [claimed-docs] “Inngest handles execution durability, state persistence, retries, and flow control for you. There are no queues to configure, no workers to …”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “By default, in addition to the initial attempt, Inngest will retry a function or a step up to 4 times until it succeeds.”
   • [claimed-docs] “Every step, every tool call, every decision the agent makes is checkpointed as it happens. If the process dies at step 7 of 12, the agent pi…”
   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”
   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet's architecture (separate control-plane service, Postgres-backed queue, retries/durability, concurrency-key limits) implies workers can be added to a fleet and tasks distributed/retried on failure (hatchet-gh-1, hatchet-gh-2, hatchet-docs-5/6/18), and the founder describes the control plane as coordinating worker execution independently of client polling (hatchet-comm-6). However, the founder's own account of a scaling pathology at ~25k queries/s with many workers long-polling causing 'runaway CPU deterioration' (hatchet-comm-11) shows real limits to clean horizontal scaling that aren't fully resolved in the evidence, and there's no explicit documentation of automatic failover/rebalancing when a worker dies. Missing for 10: explicit docs on worker-loss recovery/rebalancing, independent throughput benchmarks confirming linear scaling with added workers, and confirmation the 25k qps bottleneck is fully resolved.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [community] “pg-boss comparison from founder: 'The core difference is that pg-boss is a library while Hatchet is a separate service which runs independen…”
   • [community] “Founder on scaling: 'FOR UPDATE SKIP LOCKED does not scale to 25k queries/s'... pathological case was many tasks in backlog, many workers, w…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Inngest~partialclaimed3/10

   Inngest doesn't document any hosted-platform region/residency selection, but self-hosting (inngest-docs-9, inngest-docs-28, inngest-gh-1) lets a user deploy Inngest's own infrastructure anywhere, which indirectly gives control over data location. Missing for 10: explicit hosted-service region selection, data residency guarantees/certifications, or documentation addressing where event/state data is stored by default.

   • [claimed-docs] “While the easiest way to get started with Inngest is using our hosted platform... we understand that developers may want to self-host for a …”
   • [claimed-docs] “Self-hosting support for Inngest is supported as of the 1.0 release.”
   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   Hatchet supports full self-hosting of its Control Plane, which lets an operator choose the physical location/region of their own infrastructure and thus control data residency indirectly, but there is no documented cloud-based region-selection feature or explicit data-residency guarantee. Missing for 10: an explicit region/residency selector for Hatchet Cloud, documentation of where hosted data is stored, and compliance certifications tied to specific regions.

   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Everything in Team, plus:Unlimited users & tenants7-day data retentionAudit logs & HIPAA”
   • [claimed-docs] “Enterprise-grade security, compliance, and SSO.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Inngest~partialclaimed3/10

   Inngest offers self-hosting and bring-your-own-encryption-key middleware, which give some indirect control over data, but there is no documented data retention policy, deletion API/workflow, or explicit user-facing controls for purging stored events/run state. missing for 10: explicit data retention configuration, a documented deletion/purge API or UI control, retention period settings for events/traces/state, and any independent confirmation of these controls working.

   • [claimed-docs] “While the easiest way to get started with Inngest is using our hosted platform... we understand that developers may want to self-host for a …”
   • [claimed-docs] “For an added layer of encryption and control of your data, install encryption middleware and bring your own encryption key.”
   • [github] “Deploy your functions to your own infrastructure. Sync your application's functions with the Inngest Platform or a self-hosted Inngest serve…”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   Evidence shows fixed data-retention windows tied to pricing tiers (3-day/7-day retention) and the option to self-host the control plane, which gives an operator ultimate control over their own Postgres-backed data including deletion. However, there is no documented user-facing deletion API, configurable retention policy, or GDPR-style erasure workflow for the hosted product. missing for 10: explicit data-deletion/purge API, user-configurable retention settings, compliance documentation (e.g., GDPR erasure) beyond generic 'Audit logs & HIPAA' mention.

   • [claimed-docs] “Everything in Team, plus:Unlimited users & tenants7-day data retentionAudit logs & HIPAA”
   • [claimed-docs] “Everything in Developer, plus:10 users & 5 tenants3-day retention500 RPS throughput”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Run Hatchet yourself”
   • [claimed-docs] “Enterprise-grade security, compliance, and SSO.”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Inngest—none0/10

   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.

   ⚑ flag

   Hatchet—none0/10

   No evidence pack item mentions telemetry, usage tracking, or any opt-out mechanism for Hatchet; this is a self-hostable orchestration platform where such a privacy control is a fair question but unaddressed in the evidence.

   ⚑ flag

Exactly once

1. backend developerIdempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending

   weight 2 · round to Inngest
   Inngest~partialclaimed5/10

   Inngest provides step memoization, retries, and checkpointed resumption (docs-2, docs-15, docs-26) which help avoid re-executing already-completed side effects on retry, and rate limiting/concurrency keys (docs-12, docs-13) reduce duplicate trigger risk. However, there is no explicit documentation of idempotency keys for event deduplication or a guarantee of exactly-once step execution semantics — Inngest's model is at-least-once with retries plus memoization, not a documented idempotency-key API for dedup. missing for 10: explicit idempotency-key/event-deduplication feature docs, explicit 'exactly-once' guarantee language, and hands-on/community confirmation that duplicate triggers are prevented from double-charging or double-sending.

   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “By default, in addition to the initial attempt, Inngest will retry a function or a step up to 4 times until it succeeds.”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [claimed-docs] “Rate limiting is a hard limit on how many function runs can start within a time period. Events that exceed the rate limit are skipped and do…”

   proof ↗⚑ flag

   Hatchet—none0/10

   The evidence pack covers retries, concurrency limits, cron/scheduled runs, and rate limits, but nowhere mentions idempotency keys or exactly-once step execution guarantees to prevent duplicate side effects like double-charging. Missing for 10: any documentation of idempotency key APIs, deduplication mechanisms, or exactly-once semantics guarantees.

   ⚑ flag

Long running

1. backend developerA workflow can sleep or wait for days to months without holding a server, connection, or billable compute

   weight 2 · round to Inngest
   Inngest✓fullcommunity9/10

   Docs explicitly describe step.sleep/waitForEvent suspending execution while holding zero resources, resuming from checkpoint after arbitrarily long waits (e.g., 'suspends entirely, holding zero resources, and resumes when the approval arrives'), and this is corroborated by community usage reports of reliable long-running background jobs. missing for 10: independent benchmark/hands-on confirmation of multi-month sleeps specifically (only human-in-the-loop/hour-scale examples shown).

   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”
   • [claimed-docs] “If the process dies at step 7 of 12, the agent picks up at step 7 — not step 1. If the agent needs to wait three hours for a human to approv…”
   • [claimed-docs] “Use step.waitForEvent() to pause agent execution for human approval, then resume or abort based on the response.”
   • [community] “we've been using inngest in our product quite a bit and it's been reliable with a generous free-tier that allows us to leech off staying ser…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet's docs reference Scheduled Runs and Cron Runs, which imply workflows can be deferred to future times without an always-on process, and the control-plane architecture persists workflow state in Postgres rather than in worker memory. However, no evidence explicitly documents a 'durable sleep' primitive, confirms sleeps can span months, or states that no billable compute/connection is held during a sleep. Missing for 10: explicit sleep/durable-execution API docs, confirmation of long-duration (weeks/months) sleeps, and any statement about compute/connection cost during sleep.

   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”

   proof ↗⚑ flag

Recovery

1. backend developerA workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact

   weight 3 · round to Inngest
   Inngest✓fullcommunity9/10

   Inngest's core value proposition is durable execution: steps are memoized/checkpointed so a crashed process resumes from the last successful step rather than restarting, explicitly documented with the 'step 7 of 12' example and backed by retry, state persistence, and observability docs; community reports corroborate reliability in production use. Missing for 10: independent third-party benchmark or incident report specifically confirming crash-recovery behavior in production (only vendor docs and general reliability praise are available).

   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Every step, every tool call, every decision the agent makes is checkpointed as it happens. If the process dies at step 7 of 12, the agent pi…”
   • [claimed-docs] “If the process dies at step 7 of 12, the agent picks up at step 7 — not step 1. If the agent needs to wait three hours for a human to approv…”
   • [claimed-docs] “you write standard TypeScript, Python, or Go functions using a simple SDK, and Inngest handles execution durability, state persistence, retr…”
   • [claimed-docs] “By default, in addition to the initial attempt, Inngest will retry a function or a step up to 4 times until it succeeds.”
   • [community] “we've been using inngest in our product quite a bit and it's been reliable with a generous free-tier that allows us to leech off staying ser…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet~partialclaimed6/10

   Hatchet is explicitly marketed as a 'durable workflow' engine with automatic retries and durability built into the queuing layer (gh-1, gh-2, gh-3), and has a dedicated Retry Policies doc (hatchet-docs-25) plus separate control-plane architecture (hatchet-docs-8/17) that decouples worker crashes from task state. However, there is no first-party or community evidence detailing exact step-level checkpointing/resume semantics after a crash, deploy, or infra failure, and no hands-on confirmation from users that a workflow actually resumes mid-execution rather than restarting. Missing for 10: explicit documentation of step-level state persistence/checkpointing, and independent/hands-on evidence confirming resume-from-last-step behavior after real crashes or deploys.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [github] “An orchestration engine for background tasks, AI agents, and durable workflows”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”

   proof ↗⚑ flag

Retries

1. backend developerEvery step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding

   weight 3 · round to Inngest
   Inngest✓fullcommunity9/10

   Docs confirm automatic step-level retries (default 4 attempts) with configurable retry counts, plus concurrency, rate limiting, timeouts via waitForEvent, and memoized/checkpointed step execution that resumes without try/catch scaffolding. Community reviews corroborate reliability in production use. missing for 10: independent hands-on verification of configurable backoff policies specifically (only default retry count and general retry behavior documented explicitly).

   • [claimed-docs] “By default, in addition to the initial attempt, Inngest will retry a function or a step up to 4 times until it succeeds.”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [claimed-docs] “Rate limiting is a hard limit on how many function runs can start within a time period. Events that exceed the rate limit are skipped and do…”
   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [community] “we've been using inngest in our product quite a bit and it's been reliable with a generous free-tier that allows us to leech off staying ser…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet has a dedicated 'Retry Policies' docs page and GitHub explicitly touts 'automatic retries' as part of the platform, and the founder's HN comments describe a declarative workflow model that avoids try/catch scaffolding for step execution. However, the evidence pack gives only page titles for retries/rate-limits/concurrency without concrete detail on configurable backoff curves, per-step timeouts, or failure-policy semantics. Missing for 10: explicit documentation of backoff configuration options, timeout settings per step, and failure-policy examples beyond a bare page title.

   • [claimed-docs] “Retry Policies”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [community] “abelanger (Hatchet founder) explained: 'unlike many alternatives, the execution path of a multi-step workflow in Hatchet is declared ahead o…”
   • [claimed-docs] “Rate Limits”

   proof ↗⚑ flag

Events

1. backend developerEvents from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions

   weight 2 · round to Inngest
   Inngest✓fullcommunity9/10

   Inngest natively triggers functions from events, webhooks, or crons declaratively (event-driven SDK, unique webhook URLs, cron scheduling), and multiple functions can subscribe to the same event for fan-out, with community reports confirming reliable production use for exactly this pattern (queueing, scheduling, triggers). Missing for 10: no explicit first-party example showing many functions bound to a single event name in the evidence pack (fan-out is documented for events generally but not shown with a concrete multi-function example), and no independent benchmark of fan-out scale.

   • [claimed-docs] “Inngest enables you to create any number of unique URLs which act as webhook consumers. You can create a webhook for each third party servic…”
   • [claimed-docs] “Inngest enables you to create any number of unique URLs which act as webhook consumers. You can create a webhook for each third party servic…”
   • [claimed-docs] “Inngest's cron schedules also support timezones, allowing you to schedule work in whatever timezone you need work to run in.”
   • [claimed-docs] “You can create scheduled functions that run in any timezone using the SDK's createFunction()”
   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”
   • [claimed-docs] “Inngest handles execution durability, state persistence, retries, and flow control for you. There are no queues to configure, no workers to …”
   • [community] “Really great product, I'm using inngest since 2-3 months and it definitely solved our problem. We needed a scheduling, queue, trigger soluti…”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”

   proof ↗⚑ flag

   Hatchet~partialclaimed6/10

   Hatchet's docs show declarative workflow triggering via webhooks, event filters (CEL expressions), and cron/scheduled runs, and its DAG-based workflow model with shared concurrency rules across multiple workflows (docs-6) implies coordinated multi-workflow execution from shared triggers. However, there's no explicit worked example or documentation of a single event fanning out to multiple distinct functions/workflows, and no independent hands-on confirmation of this exact pattern. missing for 10: concrete example/doc of one event triggering multiple downstream workflows/functions, independent verification of fan-out behavior.

   • [claimed-docs] “Webhooks”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

Flow shaping

1. backend developerI debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want

   weight 1 · round drawn
   Inngest~partialclaimed4/10

   Inngest documents adjacent flow-control primitives — rate limiting to skip excess runs (inngest-docs-13), keyed concurrency limits (inngest-docs-12), and event-driven pausing/waiting via step.waitForEvent (inngest-docs-18, inngest-docs-32) — which can help collapse noisy triggers, but the evidence pack contains no explicit mention of debounce or batching functions, the specific mechanisms typically used for this exact use case. Missing for 10: explicit debounce configuration docs, batch/batchEvents documentation, and any hands-on confirmation that noisy streams are collapsed as intended.

   • [claimed-docs] “Rate limiting is a hard limit on how many function runs can start within a time period. Events that exceed the rate limit are skipped and do…”
   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet's concurrency strategies (e.g. CANCEL_QUEUED_EXCEPT_NEWEST/OLDEST) and per-key concurrency limits can approximate collapsing noisy triggers into a single desired run, and rate limits/cron/scheduled runs give some control over trigger cadence, but there is no explicit debounce, batching-window, or delay-trigger primitive described in the evidence. missing for 10: explicit debounce/delay trigger API, event batching/aggregation over a time window, and any hands-on confirmation these concurrency strategies are actually used for debounce-style use cases.

   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Concurrency”
   • [claimed-docs] “Rate Limits”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Scheduled Runs”

   proof ↗⚑ flag

Schedules

1. backend developerI schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs

   weight 2 · round drawn
   Inngest~partialclaimed5/10

   Inngest documents cron-based scheduled functions with timezone support (docs-17/31) and generic concurrency controls with keys (docs-12) that could prevent overlapping runs, plus wait-for-event pause/resume semantics (docs-18/32) and run-level observability/traces (docs-20/37). However, there is no explicit documentation of a cron-specific 'overlap policy' (e.g. skip/queue/replace on overlap) or of a dashboard view showing upcoming scheduled run times. Missing for 10: explicit overlap-policy configuration for scheduled functions, ability to pause/resume a cron schedule itself (not just a run), and a documented view of upcoming/future cron executions.

   • [claimed-docs] “Inngest's cron schedules also support timezones, allowing you to schedule work in whatever timezone you need work to run in.”
   • [claimed-docs] “You can create scheduled functions that run in any timezone using the SDK's createFunction()”
   • [claimed-docs] “Step concurrency can be optionally configured using "keys" which applies the limit to each unique value of the key (ex. user id).”
   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”
   • [claimed-docs] “Inngest captures execution data for every function run. You get metrics, traces, event logs, and per-step timing without instrumenting your …”
   • [claimed-docs] “This guide walks you through finding a failed run, pulling its trace, and identifying which step broke. You do this entirely from the termin…”

   proof ↗⚑ flag

   Hatchet~partialclaimed5/10

   Hatchet documents cron triggers, scheduled runs, and concurrency strategies (including queue-depth overlap-like policies such as CANCEL_QUEUED_EXCEPT_NEWEST/OLDEST) plus TUI/dashboard observability into tasks and workflows, giving partial coverage of scheduling and visibility. However, there is no explicit documentation tying overlap policies specifically to cron jobs, and no evidence of a pause/resume feature for scheduled workflows. Missing for 10: explicit cron-specific overlap/skip policy docs, pause/resume of cron schedules, and independent confirmation of upcoming-run visibility UI.

   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”

   proof ↗⚑ flag

Versioning

1. platform engineerI deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism

   weight 3 · round to Inngest
   Inngest✓fullclaimed8/10

   Inngest has a dedicated versioning doc stating deployments don't require explicit version markers or migration logic, and durable step/state execution means in-flight runs resume from checkpointed state so new code doesn't retroactively alter their execution path. This is corroborated by the broader durable-execution model (memoized steps, resumption from last checkpoint) which underlies deterministic replay across deploys. Missing for 10: independent/hands-on verification of the exact in-flight-run-vs-new-deploy behavior, and more detail on edge cases (e.g., changed step signatures mid-run).

   • [claimed-docs] “Inngest enables developers to deploy changes to functions without explicit version markers or complex migration logic.”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “you write standard TypeScript, Python, or Go functions using a simple SDK, and Inngest handles execution durability, state persistence, retr…”

   proof ↗⚑ flag

   Hatchet—none0/10

   No evidence describes workflow-version pinning for in-flight runs, deterministic replay guarantees, or any mechanism to keep already-started runs on the code version they began with while new versions roll out — the docs cover retries, concurrency, cron, self-hosting, and CLI tooling but never versioning/determinism semantics. This is a reasonable axis for a durable workflow engine, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

Authoring

1. backend developerI write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL

   weight 3 · round to Inngest
   Inngest✓fullcommunity9/10

   Inngest lets developers write ordinary TypeScript, Python, or Go functions with steps that are automatically checkpointed/memoized and resumed from the last successful point, with no YAML or proprietary DSL — supported by docs and corroborated by community devs praising the natural, code-first DX versus alternatives like Temporal. missing for 10: independent third-party benchmark or deeper multi-language proof beyond docs claims.

   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”
   • [claimed-docs] “you write standard TypeScript, Python, or Go functions using a simple SDK, and Inngest handles execution durability, state persistence, retr…”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [community] “We've been using Inngest at Secta.ai for the last ~6 months... DX is great! Writing the jobs feels very natural, much much simpler than Temp…”
   • [community] “My only issue was that the execution of an inngest function wasn't completely intuitive, at least in TS... Is it an actor, a step function, …”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet's SDKs (Python, TypeScript, Go, Ruby) and cookbooks show workflows/tasks defined as ordinary code rather than YAML, and 'durability'/retry features are documented, implying step-level state persistence, and a founder comment confirms multi-step execution paths are declared in code ahead of time. However, there's no explicit documentation of 'automatic checkpointing' semantics or a direct contrast against YAML/DSL approaches, and no independent hands-on report specifically validating this authoring model works smoothly in production. Missing for 10: explicit automatic-checkpointing mechanics, explicit no-DSL/no-YAML framing, independent developer confirmation of code-first authoring experience.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [community] “abelanger (Hatchet founder) explained: 'unlike many alternatives, the execution path of a multi-step workflow in Hatchet is declared ahead o…”
   • [claimed-docs] “Retry Policies”

   proof ↗⚑ flag

Composition

1. backend developerI compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination

   weight 2 · round to Inngest
   Inngest~partialclaimed6/10

   Inngest's step model supports composing durable steps, invoking/deferring child functions/workflows, and waiting for events for fan-in-like coordination (inngest-docs-2, inngest-docs-4, inngest-docs-18, inngest-docs-35), all without manual queue/worker coordination (inngest-docs-1, inngest-docs-24). However, the evidence pack lacks explicit documentation of parallel step execution primitives (e.g., Promise.all across steps) or fan-out over dynamic batches specifically, so the 'parallel steps' and 'dynamic batch fan-out/fan-in' parts of the story are only inferred, not directly evidenced. missing for 10: explicit docs on parallel step execution syntax, explicit fan-out/fan-in over dynamic batch sizes, independent hands-on example of composing these three patterns together.

   • [claimed-docs] “Put side effects, API calls, sleeps, waits, and function invocations in steps so Inngest can memoize results, retry failures independently, …”
   • [claimed-docs] “Sessions now propagate to child runs. Any run triggered by another run (via event, invoke, or defer) inherits its parent's sessions.”
   • [claimed-docs] “Use step.waitForEvent() to wait for a particular event to be received before continuing. It returns a Promise that is resolved with the rece…”
   • [claimed-docs] “You can pause a Function's run until a given event is received.”
   • [claimed-docs] “Delegation gives sub-agents their own context window, tools, and token budget. A sub-agent can be modeled as a separate Inngest function tha…”
   • [claimed-docs] “Inngest handles execution durability, state persistence, retries, and flow control for you. There are no queues to configure, no workers to …”
   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”

   proof ↗⚑ flag

   Hatchet—none0/10

   The evidence pack contains no documentation or discussion of Hatchet's DAG/parallel-step syntax, fan-out/fan-in over dynamic batches, or child-workflow composition — only a general founder comment that 'the execution path of a multi-step workflow ... is declared ahead of time' (hatchet-comm-5), which does not demonstrate these specific coordination primitives. Missing for 10: docs/examples of parallel step definitions, fan-out/fan-in over dynamic batch sizes, and child workflow invocation/spawning.

   • [community] “abelanger (Hatchet founder) explained: 'unlike many alternatives, the execution path of a multi-step workflow in Hatchet is declared ahead o…”

   proof ↗⚑ flag

Language coverage

1. backend developerI author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs

   weight 2 · round to Hatchet
   Inngest~partialcommunity5/10

   Docs confirm SDKs for TypeScript, Python, and Go with steps, retries, and flow control (inngest-docs-24, inngest-docs-25), showing multi-language support. However, there is no evidence addressing feature parity across these SDKs — most detailed docs, testing tools (Jest-compatible testing, ESLint plugin) and community feedback (inngest-comm-3) reference TypeScript specifically, suggesting Python/Go may lag behind. Missing for 10: explicit parity documentation across SDKs, Python/Go-specific testing and tooling evidence, independent confirmation of equal capabilities in non-TS SDKs.

   • [claimed-docs] “Write functions in TypeScript, Python or Go to power background and scheduled jobs, with steps built in. We handle the backend infra, queuei…”
   • [claimed-docs] “you write standard TypeScript, Python, or Go functions using a simple SDK, and Inngest handles execution durability, state persistence, retr…”
   • [claimed-docs] “This allows you to mock function state, step tooling, and inputs with a Jest-compatible API supporting all major testing frameworks, runtime…”
   • [claimed-docs] “An ESLint plugin is available at @inngest/eslint-plugin, providing rules to enforce best practices when writing Inngest functions.”
   • [community] “My only issue was that the execution of an inngest function wasn't completely intuitive, at least in TS... Is it an actor, a step function, …”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet officially ships Python, TypeScript, Go and Ruby SDKs (hatchet-gh-2, hatchet-docs-24) and community members confirm using it across multiple languages (hatchet-comm-15), supporting the core 'author in your language' claim. However, several documented features (CEL expression debugging, cron creation via Python reference) are only shown in Python-specific docs, and there is no explicit cross-SDK feature-parity matrix or changelog confirming equal capabilities across all four SDKs. Missing for 10: explicit feature-parity documentation/matrix across SDKs, confirmation that newer features (e.g., CEL debug tools, concurrency strategies) are available uniformly in Go/Ruby/TypeScript, and independent hands-on validation of parity beyond basic usability.

   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [community] “This looks very cool! I see a lot of Python in the docs; is it usable in other languages? [confirmed SDKs exist for Python, Typescript and G…”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”

   proof ↗⚑ flag