Hatchet

You write tasks as plain functions using the native SDK for TypeScript, Python or Go, and compose them into workflows when one step depends on another. Tasks are invoked from your API, scheduled for a specific time, put on a cron, or triggered by an event or an incoming webhook. The engine queues the work and pushes it to your workers, which you deploy on any container platform and which connect back to Hatchet automatically. Each task retries on failure according to the policy you set, and the full history of every task and state transition is kept, so a failure can be opened in the web UI, read as a trace, and replayed by hand. Observability is built in rather than bolted on: a real-time searchable UI, an OpenTelemetry collector that forwards traces and spans to whatever stack you already run, Prometheus metrics, and application logs with full-text search.

• •Durable Execution on Postgres - Every task and state transition is persisted, so work survives a worker crash or a deploy and can be replayed afterwards instead of reconstructed from logs.
• •Three Native SDKs - TypeScript, Python and Go, each written to be idiomatic in that language rather than a thin wrapper over one shared client.
• •Workflows, DAGs and Conditions - Tasks compose into directed graphs with complex conditions, so multi-step pipelines are declared rather than orchestrated by hand.
• •Scheduling Controls at Scale - Priorities, rate limits, fair scheduling, concurrency keys and worker slots, which is the set of controls that stops one noisy tenant starving everyone else.
• •Built-In Observability - A real-time searchable run history, an OpenTelemetry collector, Prometheus metrics and searchable application logs, rather than a separate monitoring product.
• •MIT Licensed and Self-Hostable - The whole engine runs locally from one CLI command, on Kubernetes, Docker or any container platform, with cloud and bring-your-own-cloud as options rather than requirements.

Hatchet suits teams who have outgrown a cron table and a queue library and now need to answer questions about what ran, why it failed and whether it can be re-run. It is a good fit for Python and TypeScript teams building AI agents that make long chains of tool calls, where a dropped step is expensive and a silent failure is worse, and for anyone running data ingestion pipelines who needs fairness and priority controls rather than a single FIFO. Teams migrating off Temporal or Celery are an explicit target, and the migration guides exist for that reason.

It is less obviously for you if what you need is an agent framework. Hatchet orchestrates work, and agents are one kind of work it orchestrates; a great deal of what it does is background jobs and cron replacement, so anyone arriving expecting prompt handling, tool definitions or memory will find a durable execution engine instead. Small projects with a handful of background jobs will also find a queue library simpler. The headline figures on Hatchet's homepage for tasks run daily and active projects are animated counters the company reports about itself, and are not independently verified.