Trigger.dev 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 Trigger.dev
   Trigger.dev✓fullcommunity8/10

   Trigger.dev's docs explicitly target durable AI agent loops: checkpoint-resume execution with no determinism constraints, durable multi-turn AI chat tasks that survive refreshes/deploys/crashes, waitpoint tokens for human-approval pauses mid-run, tool-level needsApproval pausing, retries with exponential backoff, and streaming/realtime updates from AI providers — closely matching the story's checkpointed/retried agent-loop pattern, corroborated by GitHub positioning ('rock solid agents') and community usage for chained OpenAI calls. missing for 10: no independent hands-on benchmark specifically demonstrating a multi-step tool-calling agent loop surviving a mid-run crash, and one community comment notes wait/resume was previously a wishlist gap suggesting maturity is still evolving.

   • [claimed-docs] “Trigger.dev uses checkpoint-resume to run normal TypeScript with no determinism constraints, processing millions of tasks for thousands of t…”
   • [claimed-docs] “Durable multi-turn AI chats — one Trigger.dev task per conversation, surviving refreshes, deploys, and crashes.”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “refundOrder: tool({ ... needsApproval: true, // pauses for human approval; the run stays alive ... })”
   • [claimed-docs] “This task will retry 10 times with exponential backoff.”
   • [claimed-docs] “Forward streams through the Realtime API to provide real-time updates to your users from any AI providers.”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”
   • [community] “The hooks are great for returning multiple values/progress updates to the UI. I've been using it for chained and/or long calls to the OpenAI…”
   • [community] “Trigger.dev is awesome, use it every day. A feature list is quite impressive and complete, the only thing on my wish-list is a wait/resume f…”

   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 to Hatchet
   Trigger.dev~partialclaimed5/10

   Trigger.dev shows generic AI-agent durability primitives — durable multi-turn chat agents (docs-13), tool-calling with human-approval pauses that mirrors AI SDK tool() conventions (docs-22), prompt/model overrides (docs-32), and realtime streaming 'from any AI providers' (docs-30) — but there is no evidence of named first-party integration packages wrapping specific AI SDKs, agent frameworks (LangChain, LlamaIndex, CrewAI, AutoGen) or model providers (OpenAI, Anthropic) the way the story describes. Support is more 'framework-agnostic durability layer' than 'first-party wrapped integrations.' Missing for 10: explicit first-party SDK/framework integration packages, a documented compatibility list of supported AI providers/agent frameworks, and independent hands-on confirmation of glue-code-free integration.

   • [claimed-docs] “Durable multi-turn AI chats — one Trigger.dev task per conversation, surviving refreshes, deploys, and crashes.”
   • [claimed-docs] “refundOrder: tool({ ... needsApproval: true, // pauses for human approval; the run stays alive ... })”
   • [claimed-docs] “Forward streams through the Realtime API to provide real-time updates to your users from any AI providers.”
   • [claimed-docs] “Create overrides to change the prompt text or model without redeploying”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”

   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 to Trigger.dev
   Trigger.dev✓fullcommunity8/10

   Trigger.dev's Realtime API is explicitly documented for streaming live run updates and token/data streams from background tasks directly to a frontend without polling, including forwarding AI provider streams for real-time UI updates, and community feedback confirms hooks are used for returning progress updates to the UI during OpenAI calls. Missing for 10: independent hands-on frontend integration examples/demos beyond docs and one community mention, and no discussion of latency/scale limits of the realtime stream in practice.

   • [claimed-docs] “Get live run updates and stream data from background tasks to your frontend or backend. No polling.”
   • [claimed-docs] “Forward streams through the Realtime API to provide real-time updates to your users from any AI providers.”
   • [community] “The hooks are great for returning multiple values/progress updates to the UI. I've been using it for chained and/or long calls to the OpenAI…”

   proof ↗⚑ 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
   Trigger.dev✓fullprobed8/10

   A probe confirms llms.txt is live and returns 200 with a proper agent-oriented summary of the product, and there's also a llms-full.txt referenced in docs, plus agent skills files for coding assistants. missing for 10: no docs.md fallback (404), no independent third-party confirmation that agents actually consume/parse this llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://trigger.dev/llms.txt # Trigger.dev > Build AI agents and workflows in TypeScript. Open source platform …”
   • [claimed-docs] “Language | TypeScript/JavaScript (Node.js and Bun); Python via build extension”
   • [claimed-docs] “Install Trigger.dev agent skills to teach any AI coding assistant how to write tasks, realtime frontends, and chat.agent AI agents.”
   • [probe] “PROBE docs-md: HTTP 404 at https://trigger.dev/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
   Trigger.dev✓fullcommunity8/10

   Trigger.dev is inherently a headless background-jobs platform: tasks run via SDK/CLI with no UI required, deploys are triggered from CI via a documented GitHub Actions workflow, and the CLI supports local dev, build, and cloud deploy commands suitable for automation pipelines. Community evidence corroborates real production/CI usage (e.g. long-term customers running it as an async backend for their apps). Missing for 10: no explicit third-party proof of arbitrary CI providers beyond GitHub Actions, and no example of fully non-interactive CLI use for run-triggering/testing in CI.

   • [claimed-docs] “This simple GitHub action workflow will deploy your Trigger.dev tasks when new code is pushed to the `main` branch.”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [claimed-docs] “Run your Trigger.dev tasks locally.”
   • [claimed-docs] “Deploy your Trigger.dev project to the cloud.”
   • [claimed-docs] “Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, de…”
   • [community] “We're very satisfied customers since January of this year. We use it as an extension of our node app, for all things asynchronous... it's th…”
   • [community] “Another happy customer here. Since day one Trigger.dev is powering our AI Automation platform. It helped us to scale effortlessly and stay o…”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”

   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
   Trigger.dev—none0/10

   Trigger.dev documents an official MCP *server* that lets external AI coding tools (Claude Code, Cursor, Windsurf) call into Trigger.dev projects — the reverse direction from this story. The story asks whether Trigger.dev, as a platform for building AI agents/tasks, lets its own agents plug in external MCP servers to use their tools; no evidence in the pack shows any MCP-client capability for Trigger.dev-built tasks or agents.

   • [claimed-docs] “The Trigger.dev MCP (Model Context Protocol) Server enables AI assistants to interact directly with your Trigger.dev projects.”
   • [claimed-docs] “The Trigger.dev MCP server includes tools for having conversations with your chat agents directly from AI coding tools like Claude Code, Cur…”
   • [claimed-docs] “This lets your AI assistant interact with your agents without writing any code.”
   • [probe] “official MCP server documented at https://trigger.dev/docs/mcp-introduction”

   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 Trigger.dev
   Trigger.dev✓fullprobed8/10

   Trigger.dev is not itself an AI coding agent but a background-jobs/agent-building platform, so the MCP-server axis applies directly, and it documents an official MCP server enabling AI assistants to interact with Trigger.dev projects, including tools for Claude Code, Cursor, and Windsurf to converse with chat agents and manage tasks without code. This is corroborated by a dedicated probe confirming the server's existence. Missing for 10: independent/hands-on community verification of the MCP server itself (community evidence is about the core platform, not MCP usage specifically).

   • [claimed-docs] “The Trigger.dev MCP (Model Context Protocol) Server enables AI assistants to interact directly with your Trigger.dev projects.”
   • [claimed-docs] “The Trigger.dev MCP server includes tools for having conversations with your chat agents directly from AI coding tools like Claude Code, Cur…”
   • [claimed-docs] “This lets your AI assistant interact with your agents without writing any code.”
   • [probe] “official MCP server documented at https://trigger.dev/docs/mcp-introduction”

   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
   Trigger.dev✓fullprobed8/10

   Trigger.dev ships an official CLI documented at cli-introduction with commands for local dev, self-hosting, and deployment (docs-16, docs-34, docs-35), corroborated by a probe confirming the docs page. This CLI is core to the developer/agentic workflow (deploy via GitHub Actions, etc.), though evidence doesn't show AI-native-specific CLI features (e.g., natural-language CLI commands) beyond standard dev tooling. Missing for 10: independent hands-on confirmation of CLI usage, and explicit AI-native CLI extensions beyond the general dev CLI.

   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [claimed-docs] “Run your Trigger.dev tasks locally.”
   • [claimed-docs] “Deploy your Trigger.dev project to the cloud.”
   • [probe] “official CLI documented at https://trigger.dev/docs/cli-introduction”

   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 Trigger.dev
   Trigger.dev✓fullprobed7/10

   Trigger.dev documents a public Management API/SDK (trigger, list runs, cancel, retry) with scoped API keys, plus a v3 SDK reference and MCP server for AI assistants to interact with projects — enabling programmatic, AI-native control of the platform. Missing for 10: a formal OpenAPI/REST spec (probe shows 404s for openapi.json/swagger.json) and independent third-party corroboration of automated API-driven usage specifically.

   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”
   • [claimed-docs] “Create as many keys as you need per environment, each with its own access scope, optional task restrictions, and an expiration date.”
   • [claimed-docs] “The Trigger.dev MCP (Model Context Protocol) Server enables AI assistants to interact directly with your Trigger.dev projects.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://trigger.dev/openapi.json, https://trigger.dev/swagger.json, https://trigger.dev/api/openapi.…”
   • [probe] “official MCP server documented at https://trigger.dev/docs/mcp-introduction”

   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 to Trigger.dev
   Trigger.dev~partialclaimed6/10

   Trigger.dev supports creating multiple API keys per environment with distinct access scope, task restrictions, and expiration dates, which is a form of scoped/least-privilege credentialing (docs-42). However, this is documented only briefly in a blog post rather than a dedicated security/credentials doc, and there's no evidence of fine-grained per-agent or per-tool scoping, role-based permission granularity, or agent-specific credential issuance workflows. missing for 10: dedicated documentation on scoped credential creation, evidence of granular per-tool/per-agent permission models, independent/hands-on confirmation of least-privilege enforcement.

   • [claimed-docs] “Create as many keys as you need per environment, each with its own access scope, optional task restrictions, and an expiration date.”
   • [claimed-docs] “Yes, you can enable Multi-Factor Authentication (MFA) on your account, adding an extra layer of authentication security for your team.”

   proof ↗⚑ 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
   Trigger.dev✓fullprobed8/10

   Trigger.dev ships an official @trigger.dev/sdk (TypeScript/JavaScript, plus Python via build extension) that underpins all task, queue, realtime, and management functionality, with extensive first-party docs and code samples, and community evidence confirms developers build production AI agent workloads directly against it. missing for 10: no official OpenAPI spec or multi-language SDK beyond TS/Python, and no independent third-party SDK quality audit.

   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”
   • [claimed-docs] “Language | TypeScript/JavaScript (Node.js and Bun); Python via build extension”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”
   • [community] “co-founder of Magic Patterns: We use Trigger to take screenshots of designs... Puppeteer constantly hits OOM errors, needing a high-end mach…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://trigger.dev/openapi.json, https://trigger.dev/swagger.json, https://trigger.dev/api/openapi.…”

   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 Hatchet
   Trigger.dev—none0/10

   The evidence shows Trigger.dev can send outbound webhook alerts when tasks fail (docs-29) and supports many trigger types (scheduled, API calls, waitpoint tokens), but there is no documentation of an inbound webhook subscription mechanism that lets a task be triggered by external events via webhooks. This is a fair axis for a background-jobs/workflow platform, but no evidence shows it delivers 'subscribe to events via webhooks' as a capability.

   • [claimed-docs] “Receive alerts via email, Slack notification and webhooks when your tasks fail.”
   • [claimed-docs] “This triggers the task and returns a handle...You can use the handle to check the status of the task, cancel and retry it.”
   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”

   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 drawn
   Trigger.dev✓fullcommunity8/10

   Trigger.dev is purpose-built for autonomous background automation: scheduled/cron tasks, durable long-running executions with no timeouts, retries, queues/concurrency control, waitpoints for pausing/resuming, and real-time monitoring, explicitly marketed for building AI agents. Community evidence confirms production use for autonomous background jobs (e.g. screenshot pipeline, AI automation platform) running reliably without manual intervention. Missing for 10: independent long-term reliability benchmarks and more detail on fully autonomous multi-step agent orchestration beyond single-task/chat use cases.

   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”
   • [claimed-docs] “Scheduled tasks are only for recurring tasks...A task that is triggered on a recurring schedule using cron syntax.”
   • [claimed-docs] “Add schedules to your tasks which sync when you run dev or deploy”
   • [claimed-docs] “Create, activate, disable, edit and delete schedules in the dashboard without having to deploy any new code.”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”
   • [community] “co-founder of Magic Patterns: We use Trigger to take screenshots of designs... Puppeteer constantly hits OOM errors, needing a high-end mach…”
   • [community] “Another happy customer here. Since day one Trigger.dev is powering our AI Automation platform. It helped us to scale effortlessly and stay o…”
   • [community] “Big fan of Trigger.dev here. The scheduled task feature has been a lifesaver—super simple and just works exactly as expected. Also want to c…”

   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 Trigger.dev
   Trigger.dev~partialprobed6/10

   Trigger.dev ships an official MCP server that lets AI assistants (Claude Code, Cursor, Windsurf) interact with projects and chat agents via natural language, and 'agent skills' teach coding assistants to write tasks — this enables natural-language operation indirectly through AI coding tools rather than a built-in NL interface in the product itself. missing for 10: no evidence of a native chat/NL command interface within Trigger.dev's own dashboard or CLI, no independent hands-on validation of the MCP server's reliability for full task lifecycle control via natural language.

   • [claimed-docs] “The Trigger.dev MCP (Model Context Protocol) Server enables AI assistants to interact directly with your Trigger.dev projects.”
   • [claimed-docs] “The Trigger.dev MCP server includes tools for having conversations with your chat agents directly from AI coding tools like Claude Code, Cur…”
   • [claimed-docs] “Install Trigger.dev agent skills to teach any AI coding assistant how to write tasks, realtime frontends, and chat.agent AI agents.”
   • [claimed-docs] “This lets your AI assistant interact with your agents without writing any code.”
   • [probe] “official MCP server documented at https://trigger.dev/docs/mcp-introduction”

   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
   Trigger.dev—none0/10

   Trigger.dev docs contain static code snippets (e.g. docs-19, docs-36) but there is no evidence of an interactive API reference with runnable/executable examples, and probes explicitly show no OpenAPI/swagger spec exists (trigger-dev-probe-3) and no machine-readable docs.md (trigger-dev-probe-2).

   • [probe] “PROBE openapi: all candidate paths 404 (https://trigger.dev/openapi.json, https://trigger.dev/swagger.json, https://trigger.dev/api/openapi.…”
   • [probe] “PROBE docs-md: HTTP 404 at https://trigger.dev/docs.md”
   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”

   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
   Trigger.dev—none0/10

   A direct probe found no OpenAPI/Swagger spec at any standard location (all 404s), and no documentation references a downloadable machine-readable API spec despite an SDK/management API existing.

   • [probe] “PROBE openapi: all candidate paths 404 (https://trigger.dev/openapi.json, https://trigger.dev/swagger.json, https://trigger.dev/api/openapi.…”
   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”

   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 Trigger.dev
   Trigger.dev~partialcommunity6/10

   Trigger.dev supports separate environments (dev/staging/prod) with the CLI 'dev' mode for local testing and community praise calling Dev mode 'an absolute gem' for testing/iterating without touching production, plus API keys scoped per environment. However, there is no explicit documentation of a dedicated 'sandbox' environment type or built-in data isolation/masking guarantees separating test runs from production data. missing for 10: explicit sandbox environment documentation, data isolation guarantees between environments, independent verification that dev/test runs cannot touch production data.

   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [claimed-docs] “Run your Trigger.dev tasks locally.”
   • [claimed-docs] “Create as many keys as you need per environment, each with its own access scope, optional task restrictions, and an expiration date.”
   • [community] “Big fan of Trigger.dev here. The scheduled task feature has been a lifesaver—super simple and just works exactly as expected. Also want to c…”

   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 to Trigger.dev
   Trigger.dev!disputedcontradicted4/10

   Trigger.dev documents version-locking of task runs (docs-7) and references its v3 SDK module (docs-36), implying some notion of API versioning, but there is no explicit documented deprecation policy page, and a direct hands-on report describes the v3→v4 migration as 'rushed' with docs/examples still showing deprecated v3 code (comm-13), contradicting the idea of a well-managed, documented deprecation process. missing for 10: an explicit versioned-API/deprecation-policy document, evidence of advance-notice or migration guides, and independent confirmation the v3→v4 transition was smooth.

   • [claimed-docs] “When a task run starts it is locked to the latest version of the code (for that environment). Once locked it won't change versions, even if …”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”
   • [community] “We've had some issues with migrating from v3 to v4. The transition felt rushed (some of the docs / examples are still showing v3 code, that …”

   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 drawn
   Trigger.dev~partialclaimed5/10

   Trigger.dev's SDK and dashboard support querying/filtering many runs at once (runs.list with status filters) and infrastructure like concurrency limits/keys and queues allows large numbers of items to be processed in parallel, which indirectly enables bulk-style automation. However, there is no explicit documentation of a dedicated 'batch trigger' or bulk cancel/update API for operating on many items in a single call. Missing for 10: explicit bulk/batch trigger API, bulk cancel/retry/update operations across many runs, and independent confirmation of bulk-scale usage.

   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “With concurrency keys you can create bespoke queue logic for each of your users.”
   • [claimed-docs] “You can view your current limits, quotas, and rate limit usage in real-time by visiting the **Limits** page in the dashboard”

   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 Hatchet
   Trigger.dev~partialclaimed6/10

   Trigger.dev supports event/schedule-triggered task execution (cron schedules, triggering via SDK, webhooks, waitpoints for external confirmation) and automates actions like retries, approvals, and AI agent workflows, but this is developer-defined trigger-and-task code rather than declarative 'if event then action' rule authoring aimed at non-developer AI-native users. missing for 10: a declarative rule/condition-builder UI or natural-language rule definition interface, and independent evidence of end-to-end 'rule triggers action' automation beyond scheduled/event-based task invocation.

   • [claimed-docs] “Scheduled tasks are only for recurring tasks...A task that is triggered on a recurring schedule using cron syntax.”
   • [claimed-docs] “Add schedules to your tasks which sync when you run dev or deploy”
   • [claimed-docs] “Create, activate, disable, edit and delete schedules in the dashboard without having to deploy any new code.”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “refundOrder: tool({ ... needsApproval: true, // pauses for human approval; the run stays alive ... })”
   • [claimed-docs] “This triggers the task and returns a handle...You can use the handle to check the status of the task, cancel and retry it.”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”

   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 Trigger.dev
   Trigger.dev✓fullcommunity9/10

   Trigger.dev has first-class scheduled/recurring tasks using cron syntax, with dashboard management (create/edit/disable without redeploy) and syncing on deploy, plus community corroboration that the scheduled task feature 'just works exactly as expected'. missing for 10: independent hands-on evidence specifically stress-testing recurring schedule reliability at scale beyond the single community quote.

   • [claimed-docs] “Scheduled tasks are only for recurring tasks...A task that is triggered on a recurring schedule using cron syntax.”
   • [claimed-docs] “Add schedules to your tasks which sync when you run dev or deploy”
   • [claimed-docs] “Create, activate, disable, edit and delete schedules in the dashboard without having to deploy any new code.”
   • [community] “Big fan of Trigger.dev here. The scheduled task feature has been a lifesaver—super simple and just works exactly as expected. Also want to c…”

   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 Trigger.dev
   Trigger.dev~partialclaimed4/10

   Trigger.dev documents a versioning concept where task runs lock to the code version deployed at trigger time (trigger-dev-docs-7), and deployment is managed via git/GitHub Actions (trigger-dev-docs-18), which implies git-based version history. However, there is no documented in-dashboard review UI, diffing, or explicit rollback mechanism to revert a deployed automation to a prior version. Missing for 10: explicit rollback/revert capability in the dashboard or CLI, a change-review workflow, and any audit trail for reviewing prior automation versions before promoting them.

   • [claimed-docs] “When a task run starts it is locked to the latest version of the code (for that environment). Once locked it won't change versions, even if …”
   • [claimed-docs] “This simple GitHub action workflow will deploy your Trigger.dev tasks when new code is pushed to the `main` branch.”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”

   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 Trigger.dev
   Trigger.dev~partialprobed4/10

   The CLI clearly supports running the whole engine locally with one command (`trigger dev`), and community feedback praises 'Dev mode' for smooth local testing/iteration, but there is no evidence of dedicated unit-testing utilities, time-skipping, or step-mocking APIs for workflows. Missing for 10: documented unit-test/testing framework integration, time-travel/time-skip simulation, and mocked-step APIs.

   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [claimed-docs] “Run your Trigger.dev tasks locally.”
   • [probe] “official CLI documented at https://trigger.dev/docs/cli-introduction”
   • [community] “Big fan of Trigger.dev here. The scheduled task feature has been a lifesaver—super simple and just works exactly as expected. Also want to c…”

   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 Trigger.dev
   Trigger.dev✓fullclaimed8/10

   Docs explicitly describe waitpoint tokens that pause task runs until manually completed, used commonly for approval workflows, plus a tool-level `needsApproval` example showing the run stays alive awaiting human input. This directly matches the described story of long-duration human-in-the-loop pausing and resuming. Missing for 10: independent/hands-on confirmation of multi-day pause durations in production (older community comments from before this feature shipped wished for 'wait/resume' but don't contradict the current documented capability).

   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows”
   • [claimed-docs] “refundOrder: tool({ ... needsApproval: true, // pauses for human approval; the run stays alive ... })”

   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 Trigger.dev
   Trigger.dev✓fullclaimed8/10

   Trigger.dev supports waitpoint tokens to pause a running task until an external API call completes them (commonly used for human approval/webhook confirmation), management API/SDK calls like runs.list to trigger, cancel, or interact with runs externally, and realtime/streaming APIs to push updates into or out of running tasks. This directly covers sending signals/events from outside (API, webhook, or another workflow) into a running workflow. missing for 10: no explicit example of triggering a waitpoint token from a webhook payload end-to-end, and no independent/hands-on confirmation of external signal delivery beyond docs.

   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows”
   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “Get live run updates and stream data from background tasks to your frontend or backend. No polling.”
   • [claimed-docs] “refundOrder: tool({ ... needsApproval: true, // pauses for human approval; the run stays alive ... })”
   • [claimed-docs] “This triggers the task and returns a handle...You can use the handle to check the status of the task, cancel and retry it.”

   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 drawn
   Trigger.dev~partialprobed4/10

   Trigger.dev provides built-in observability (run traces, states, Limits/concurrency usage page) and can alert via email, Slack, and webhooks when tasks fail, which covers the alerting half of the story. However, there is no evidence of exporting metrics (failure rates, latencies, queue depths) to external observability stacks like Prometheus, Datadog, or via OpenTelemetry — only proprietary dashboard views and webhook-based alerts are documented, and no OpenAPI/metrics export endpoint was found by probes. missing for 10: OpenTelemetry or Prometheus-compatible metrics export, documented integration with third-party observability stacks (Datadog/Grafana), independent confirmation that webhook alerts feed into external monitoring pipelines.

   • [claimed-docs] “As soon as you trigger a task, the run page will show a trace view of each task executing in real-time along with any logs it produces.”
   • [claimed-docs] “Receive alerts via email, Slack notification and webhooks when your tasks fail.”
   • [claimed-docs] “You can view your current limits, quotas, and rate limit usage in real-time by visiting the **Limits** page in the dashboard”
   • [claimed-docs] “A run can go through **various** states during its lifecycle...Pending version...Delayed...Queued...Dequeued...Executing”
   • [probe] “PROBE openapi: all candidate paths 404 (https://trigger.dev/openapi.json, https://trigger.dev/swagger.json, https://trigger.dev/api/openapi.…”

   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 Trigger.dev
   Trigger.dev~partialclaimed4/10

   Docs confirm a task run can be retried/cancelled via its handle (trigger-dev-docs-3) and that automatic retries with backoff exist (trigger-dev-docs-4), but there is no evidence of a dashboard/API 'replay from history' feature or of rerunning from a specific intermediate step. missing for 10: explicit replay-from-recorded-history UI/API, step-level resume/rerun capability, independent confirmation of this workflow.

   • [claimed-docs] “This triggers the task and returns a handle...You can use the handle to check the status of the task, cancel and retry it.”
   • [claimed-docs] “This task will retry 10 times with exponential backoff.”
   • [claimed-docs] “A run can go through **various** states during its lifecycle...Pending version...Delayed...Queued...Dequeued...Executing”

   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 Trigger.dev
   Trigger.dev✓fullclaimed8/10

   Docs describe a per-run trace view showing each step executing in real-time with logs (docs-28), explicit run lifecycle states (docs-10), configurable retries with backoff (docs-4), a searchable/filterable runs list with custom 'smart columns' pulled from payload/metadata/output via JSON path (docs-1), a management API to query runs by status (docs-19), and failure alerting via email/Slack/webhooks (docs-29) — together covering inputs, outputs, retries, errors, search and filter in a dashboard. Missing for 10: independent/hands-on confirmation of per-step input/output granularity in the trace UI and no community citation specifically validating the timeline/search UX beyond vendor docs.

   • [claimed-docs] “As soon as you trigger a task, the run page will show a trace view of each task executing in real-time along with any logs it produces.”
   • [claimed-docs] “A run can go through **various** states during its lifecycle...Pending version...Delayed...Queued...Dequeued...Executing”
   • [claimed-docs] “This task will retry 10 times with exponential backoff.”
   • [claimed-docs] “Show, hide, and reorder the columns on the runs list, and add smart columns that pull a value out of a run's payload, metadata, or output by…”
   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “Receive alerts via email, Slack notification and webhooks when your tasks fail.”

   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 to Trigger.dev
   Trigger.dev~partialprobed6/10

   Trigger.dev exposes a substantial Management SDK/API (trigger, cancel, retry, runs.list, waitpoints) and a CLI/MCP server for AI-native workflows, giving strong programmatic parity for core task operations. However, several UI-only capabilities are explicitly documented as dashboard-exclusive (e.g., purchasing extra concurrency 'via the dashboard' and schedule management 'without having to deploy code' implying UI as primary path), and no public OpenAPI/REST spec was discoverable (404s on all probed endpoints), suggesting the API surface may not fully mirror every UI action. Missing for 10: documented API/SDK equivalents for concurrency purchasing and full schedule CRUD parity, a public OpenAPI spec, and independent confirmation that all dashboard actions are scriptable.

   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “This triggers the task and returns a handle...You can use the handle to check the status of the task, cancel and retry it.”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “Extra concurrency above the Pro tier limit is available via the dashboard. Click the "Concurrency" page from the left sidebar when on the Pr…”
   • [claimed-docs] “Create, activate, disable, edit and delete schedules in the dashboard without having to deploy any new code.”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://trigger.dev/openapi.json, https://trigger.dev/swagger.json, https://trigger.dev/api/openapi.…”
   • [probe] “official MCP server documented at https://trigger.dev/docs/mcp-introduction”

   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 to Trigger.dev
   Trigger.dev~partialclaimed5/10

   Trigger.dev is open source (GitHub) and self-hostable, giving strong platform-level openness — a cloud user can move their entire task/queue definitions and infrastructure to self-hosted without lock-in, and the Management SDK/API (`runs.list`) exposes run data programmatically. However there's no documented bulk data-export feature, no mention of open standard export formats (e.g. JSON/CSV dump of all historical runs, logs, traces) for cloud users, and no explicit account/data portability or migration tooling beyond self-hosting the runtime itself. Missing for 10: dedicated data-export/portability docs, open-format bulk export of run history/logs, and independent confirmation that cloud data can be fully extracted.

   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”
   • [claimed-docs] “Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, de…”
   • [claimed-docs] “async function main() { const completedRuns = await runs.list({ limit: 10, status: ["COMPLETED"], }); }”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”

   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 Trigger.dev
   Trigger.dev✓fullclaimed7/10

   Trigger.dev is explicitly described as an 'open source background jobs framework' with its source hosted publicly on GitHub (triggerdotdev/trigger.dev), satisfying the ability to read the source under an open license. Missing for 10: explicit mention of the specific license name (e.g., MIT/Apache) and independent confirmation of license terms beyond the 'open source' label.

   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”

   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
   Trigger.dev✓fullclaimed7/10

   Trigger.dev is explicitly open source and documents a dedicated self-hosting overview describing full control over infrastructure, deployment, and URLs, plus CLI support for self-hosting and deployment via GitHub Actions. Missing for 10: independent/hands-on community reports specifically confirming successful self-hosting deployments (comm-19 only mentions considering self-hosting alternatives, not actually running Trigger.dev self-hosted) and deeper detail on self-hosted feature parity/limitations.

   • [claimed-docs] “Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, de…”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [claimed-docs] “This simple GitHub action workflow will deploy your Trigger.dev tasks when new code is pushed to the `main` branch.”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”

   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 Hatchet
   Trigger.dev—none0/10

   Evidence shows only two deployment modes: fully managed cloud (trigger.dev Cloud) and fully self-hosted (docs-17, run and manage the entire platform yourself). There is no documentation of a hybrid model where the vendor retains the orchestration control plane while workers execute in the customer's own infrastructure.

   • [claimed-docs] “Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, de…”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [claimed-docs] “Trigger.dev uses checkpoint-resume to run normal TypeScript with no determinism constraints, processing millions of tasks for thousands of t…”

   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 to Hatchet
   Trigger.dev~partialclaimed6/10

   Trigger.dev documents concurrencyLimit per task/queue and 'concurrency keys' explicitly designed to create bespoke per-user/tenant queue logic so one hot customer can't starve others, plus a dashboard Limits page showing usage and the ability to buy extra concurrency. However, evidence only shows concurrency capping, not a distinct configurable rate-limit (requests/time-window) mechanism per key or tenant—'rate limit usage' is only mentioned as a viewable metric, not a settable policy. Missing for 10: explicit rate-limit (throughput/time-window) configuration API per key/tenant, independent hands-on confirmation of multi-tenant isolation under load.

   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “With concurrency keys you can create bespoke queue logic for each of your users.”
   • [claimed-docs] “You can view your current limits, quotas, and rate limit usage in real-time by visiting the **Limits** page in the dashboard”
   • [claimed-docs] “Extra concurrency above the Pro tier limit is available via the dashboard. Click the "Concurrency" page from the left sidebar when on the Pr…”

   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 drawn
   Trigger.dev~partialclaimed4/10

   Trigger.dev supports concurrency keys to create 'bespoke queue logic for each of your users' (docs-27) and per-task concurrency limits (docs-8), which enables per-tenant queue isolation rather than a single global FIFO queue, addressing the 'fair scheduling across tenants' part of the story. However, there is no documented run-level priority field or priority-based scheduling mechanism in the evidence pack. Missing for 10: explicit run priority assignment/API, documentation of priority-based ordering within or across queues, and independent confirmation of fairness under contention.

   • [claimed-docs] “With concurrency keys you can create bespoke queue logic for each of your users.”
   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “Extra concurrency above the Pro tier limit is available via the dashboard. Click the "Concurrency" page from the left sidebar when on the Pr…”

   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 drawn
   Trigger.dev~partialcommunity6/10

   Trigger.dev's managed platform docs claim 'elastic scaling' with 'nothing to provision' and auto-scaling managed infrastructure, plus concurrency limits/keys and queue-based load distribution across runs, and a customer testimonial (Magic Patterns) describes Trigger spinning up jobs reliably without crashing under load. However there's no explicit documentation of worker-fleet load-balancing mechanics or worker-loss/failover tolerance from a platform-engineer's infra perspective — the docs focus on task-level retries/durability rather than describing how the underlying worker fleet is scaled or how it tolerates node failure. missing for 10: explicit docs on horizontal worker fleet scaling mechanics, load-balancing algorithm details, and documented behavior/guarantees when a worker node is lost mid-execution.

   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”
   • [claimed-docs] “Trigger.dev uses checkpoint-resume to run normal TypeScript with no determinism constraints, processing millions of tasks for thousands of t…”
   • [claimed-docs] “Trigger.dev is a managed compute platform where those same jobs get durability, observability, and auto-scaling with nothing to provision.”
   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “With concurrency keys you can create bespoke queue logic for each of your users.”
   • [community] “co-founder of Magic Patterns: We use Trigger to take screenshots of designs... Puppeteer constantly hits OOM errors, needing a high-end mach…”

   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 to Hatchet
   Trigger.dev—none0/10

   The evidence pack shows self-hosting is possible (giving implicit control over infrastructure location) and mentions a BAA add-on for PHI compliance, but there is no documentation of selectable data regions, residency guarantees, or region choice for the managed cloud offering.

   • [claimed-docs] “Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, de…”
   • [claimed-docs] “To run tasks that process PHI on Trigger.dev Cloud you'll need a signed BAA with us, which is available as a paid add-on.”

   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 to Hatchet
   Trigger.dev—none0/10

   The evidence pack covers security features like MFA, BAA for PHI, and self-hosting for infrastructure control, but contains no documentation of data retention policies, configurable retention periods, or deletion controls/APIs for run data, payloads, or logs. Self-hosting (trigger-dev-docs-17) implies infrastructure control but is not itself evidence of a retention/deletion feature.

   ⚑ 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
   Trigger.dev—none0/10

   No evidence pack item discusses telemetry, usage tracking, or an opt-out setting; self-hosting is mentioned but not tied to any telemetry disclosure/control. This is a fair axis for a dev platform/CLI product, so absence of evidence yields 'none'. Missing for 10: any mention of telemetry collection, an opt-out flag/env var, or privacy documentation addressing usage tracking.

   • [claimed-docs] “Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, de…”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”

   proof ↗⚑ 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 Trigger.dev
   Trigger.dev~partialclaimed4/10

   The GitHub README explicitly claims idempotency alongside durable tasks, retries, and queues, and the docs pack shows adjacent reliability primitives (retry/backoff, run locking/versioning, concurrency limits, waitpoint tokens for pausing on external confirmation) that support building exactly-once-like workflows. However, there is no dedicated documentation snippet showing an idempotencyKey API, how duplicate triggers are deduped, or explicit 'exactly-once step semantics' guarantees, and no independent/hands-on confirmation of dedupe behavior. Missing for 10: idempotency-key API docs/examples, explicit exactly-once semantics documentation, and community/hands-on validation of duplicate-trigger prevention.

   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”
   • [claimed-docs] “This task will retry 10 times with exponential backoff.”
   • [claimed-docs] “When a task run starts it is locked to the latest version of the code (for that environment). Once locked it won't change versions, even if …”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”

   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 Trigger.dev
   Trigger.dev✓fullclaimed7/10

   Trigger.dev's checkpoint-resume execution model explicitly decouples a paused run from server/connection compute ('no determinism constraints, processing millions of tasks... with checkpoint-resume'), tasks have no timeouts, and waitpoint tokens let a run pause indefinitely for external confirmation/approval without holding compute. This directly matches sleeping/waiting workflows without billable compute held. missing for 10: explicit documentation of maximum sleep/wait duration (days-to-months) and independent/hands-on confirmation that long waits don't accrue compute billing.

   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows”
   • [claimed-docs] “Trigger.dev uses checkpoint-resume to run normal TypeScript with no determinism constraints, processing millions of tasks for thousands of t…”
   • [claimed-docs] “you can write code that runs for a long time here, there are no timeouts”
   • [claimed-docs] “A run can go through **various** states during its lifecycle...Pending version...Delayed...Queued...Dequeued...Executing”
   • [claimed-docs] “refundOrder: tool({ ... needsApproval: true, // pauses for human approval; the run stays alive ... })”

   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 Trigger.dev
   Trigger.dev✓fullcommunity7/10

   Trigger.dev's architecture is explicitly built on checkpoint-resume durability so tasks 'run normal TypeScript with no determinism constraints' and survive infrastructure issues; docs describe automatic retries with backoff, waitpoint tokens that pause/resume runs, version-locking so in-flight runs aren't affected by new deploys, and durable AI chats explicitly 'surviving refreshes, deploys, and crashes.' A community reference (Magic Patterns) also confirms real-world resilience where a custom process crashed under load but Trigger.dev jobs 'just worked.' Missing for 10: independent/hands-on verification of an actual mid-run crash-and-resume test and more detail on exactly how much step-level state is preserved versus re-executed.

   • [claimed-docs] “Trigger.dev uses checkpoint-resume to run normal TypeScript with no determinism constraints, processing millions of tasks for thousands of t…”
   • [claimed-docs] “Durable multi-turn AI chats — one Trigger.dev task per conversation, surviving refreshes, deploys, and crashes.”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows”
   • [claimed-docs] “This task will retry 10 times with exponential backoff.”
   • [claimed-docs] “When a task run starts it is locked to the latest version of the code (for that environment). Once locked it won't change versions, even if …”
   • [community] “co-founder of Magic Patterns: We use Trigger to take screenshots of designs... Puppeteer constantly hits OOM errors, needing a high-end mach…”

   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 Trigger.dev
   Trigger.dev✓fullclaimed8/10

   Docs explicitly show configurable retry with exponential backoff ('retry 10 times with exponential backoff'), no-timeout long-running task support, concurrency/queue controls, and failure alerting via email/Slack/webhooks — all without requiring manual try/catch scaffolding since retries are declarative task config. GitHub repo tagline also highlights 'durable tasks, retries, queues and idempotency' as core primitives. Missing for 10: explicit documentation of per-step (vs per-task) granular failure policies and more detailed backoff/timeout configuration options beyond the single example, plus independent hands-on verification of retry behavior under real failures.

   • [claimed-docs] “This task will retry 10 times with exponential backoff.”
   • [claimed-docs] “This task will retry 10”
   • [claimed-docs] “you can write code that runs for a long time here, there are no timeouts”
   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “Receive alerts via email, Slack notification and webhooks when your tasks fail.”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”

   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 drawn
   Trigger.dev~partialcommunity6/10

   Trigger.dev supports declarative task definitions triggered via SDK calls, scheduled cron tasks, webhooks-style event triggering via the SDK's trigger()/batchTrigger(), and fan-out is achievable via triggering multiple tasks or using batch triggers, with concurrency/queue controls. However, the evidence pack lacks explicit documentation of native webhook ingestion endpoints, queue-consumer triggers (e.g., SQS/Kafka), or a built-in event-bus/pub-sub fan-out primitive — fan-out is implied via code composition (calling multiple tasks) rather than a first-class declarative one-event-to-many-functions construct. missing for 10: native webhook trigger endpoints, direct queue/broker integration triggers, and a first-class declarative fan-out/event-routing primitive (vs. manual invocation of multiple tasks).

   • [claimed-docs] “This triggers the task and returns a handle...You can use the handle to check the status of the task, cancel and retry it.”
   • [claimed-docs] “Scheduled tasks are only for recurring tasks...A task that is triggered on a recurring schedule using cron syntax.”
   • [claimed-docs] “Add schedules to your tasks which sync when you run dev or deploy”
   • [claimed-docs] “Create, activate, disable, edit and delete schedules in the dashboard without having to deploy any new code.”
   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “With concurrency keys you can create bespoke queue logic for each of your users.”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”
   • [community] “I moved from n8n to trigger.dev a month ago. Maintaining all the workflows in GUI was just too time consuming and difficult... not maintaini…”

   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 to Hatchet
   Trigger.dev~partialclaimed3/10

   Trigger.dev has concurrency limits and per-key queueing (docs-8, docs-27) that can throttle noisy invocations, and a 'Delayed' run state (docs-10) hints at delay support, but there is no explicit documentation of a debounce or event-batching primitive that collapses multiple triggers into a single run as the story describes. missing for 10: explicit debounce/collapse API, batch-trigger documentation, and independent confirmation these mechanisms achieve event collapsing rather than just concurrency throttling.

   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “With concurrency keys you can create bespoke queue logic for each of your users.”
   • [claimed-docs] “A run can go through **various** states during its lifecycle...Pending version...Delayed...Queued...Dequeued...Executing”

   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 to Trigger.dev
   Trigger.dev~partialcommunity6/10

   Trigger.dev documents cron-based scheduled tasks and dashboard controls to create, activate, disable, edit and delete schedules without redeploying (functionally pause/resume), plus a runs list and lifecycle states for visibility into execution. However, there is no evidence of explicit 'overlap policy' controls (e.g., skip/queue/cancel overlapping runs) or a dedicated 'upcoming runs' preview/calendar view. Missing for 10: documented overlap-policy configuration for cron schedules, and a specific upcoming-runs forecast/preview feature.

   • [claimed-docs] “Scheduled tasks are only for recurring tasks...A task that is triggered on a recurring schedule using cron syntax.”
   • [claimed-docs] “Add schedules to your tasks which sync when you run dev or deploy”
   • [claimed-docs] “Create, activate, disable, edit and delete schedules in the dashboard without having to deploy any new code.”
   • [claimed-docs] “A run can go through **various** states during its lifecycle...Pending version...Delayed...Queued...Dequeued...Executing”
   • [community] “Big fan of Trigger.dev here. The scheduled task feature has been a lifesaver—super simple and just works exactly as expected. Also want to c…”

   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 Trigger.dev
   Trigger.dev✓fullclaimed8/10

   Docs explicitly state runs lock to the code version active at start and never change versions even after new deploys, directly addressing deterministic in-flight execution across deployments; run lifecycle states and deployment/CLI docs corroborate this workflow. missing for 10: independent/hands-on community confirmation specifically of version-locking behavior during a live deploy, and no detail on how long old versions remain servable/rollback edge cases.

   • [claimed-docs] “When a task run starts it is locked to the latest version of the code (for that environment). Once locked it won't change versions, even if …”
   • [claimed-docs] “A run can go through **various** states during its lifecycle...Pending version...Delayed...Queued...Dequeued...Executing”
   • [claimed-docs] “The Trigger.dev CLI has a number of options and commands to help you develop locally, self host, and deploy your tasks.”
   • [claimed-docs] “This simple GitHub action workflow will deploy your Trigger.dev tasks when new code is pushed to the `main` branch.”

   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 Trigger.dev
   Trigger.dev✓fullcommunity8/10

   Trigger.dev workflows are written as plain async TypeScript/JavaScript (and Python via extension) functions with no YAML/DSL, using checkpoint-resume for durability (no determinism constraints), retries, and waitpoints — validated by both docs and community devs who moved from GUI/DSL tools (n8n) to code. missing for 10: independent hands-on benchmark of 'automatic checkpointing' correctness at scale, and broader language support beyond TS/Python.

   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”
   • [claimed-docs] “Trigger.dev uses checkpoint-resume to run normal TypeScript with no determinism constraints, processing millions of tasks for thousands of t…”
   • [claimed-docs] “This task will retry 10 times with exponential backoff.”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “Language | TypeScript/JavaScript (Node.js and Bun); Python via build extension”
   • [community] “I moved from n8n to trigger.dev a month ago. Maintaining all the workflows in GUI was just too time consuming and difficult... not maintaini…”

   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 Trigger.dev
   Trigger.dev~partialclaimed4/10

   Trigger.dev's task model supports triggering sub-tasks with returned handles (docs-3), waitpoints for pausing/resuming (docs-6), and per-queue concurrency limits (docs-8), which are coordination primitives useful for workflow composition, and it's positioned as a background-jobs framework for complex workflows (docs-2, gh-1). However, the evidence pack never explicitly documents batch/fan-out-fan-in triggering, parallel step orchestration, or nested child-workflow patterns as first-class constructs. Missing for 10: explicit docs on batchTrigger/fan-out over dynamic collections, fan-in aggregation of results, and child-workflow nesting patterns; independent hands-on confirmation of these specific patterns.

   • [claimed-docs] “This triggers the task and returns a handle...You can use the handle to check the status of the task, cancel and retry it.”
   • [claimed-docs] “Waitpoint tokens pause task runs until you complete the token. They're commonly used for approval workflows and other scenarios where you ne…”
   • [claimed-docs] “You can set the concurrency limit for a task by setting the `concurrencyLimit` property on the task's queue. This limits the number of runs …”
   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”
   • [github] “Build rock solid agents and AI applications using our durable tasks, retries, queues and idempotency.”

   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
   Trigger.dev~partialclaimed2/10

   Trigger.dev's own docs describe TypeScript/JavaScript (Node.js and Bun) as the core language, with Python support only 'via build extension' and no mention of Go or other languages at all — this is far from 'real feature parity' across multiple SDKs as the story requires. Missing for 10: native first-class Go SDK, native first-class Python SDK with parity (not a build-extension workaround), and any evidence of equivalent feature sets across languages.

   • [claimed-docs] “Language | TypeScript/JavaScript (Node.js and Bun); Python via build extension”
   • [claimed-docs] “All `v3` functionality is provided through the `@trigger.dev/sdk` module.”
   • [claimed-docs] “Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI task…”

   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