Trigger.dev positions itself as a developer-first Zapier alternative, but the architecture reveals something more useful: a set of orchestration primitives that agent workflows need. The platform lets you write event-driven background tasks directly in TypeScript, with durable execution, retry logic, and observability baked in. When an agent needs to call three APIs, wait for a webhook, retry on failure, and resume after a crash, you need exactly these primitives.
The project launched on Hacker News with 745 points and 190 comments. The discussion exposed a common pain point: visual automation builders (Zapier, n8n) break down when workflows become programmatic. Trigger.dev flips the model. You write tasks in code, deploy them, and the platform handles durability, retries, and state persistence.
Architecture: Tasks as First-Class Citizens
Trigger.dev treats tasks as durable units of work. You define a task with a unique ID, write the logic in TypeScript, and the platform guarantees execution even across redeploys or crashes.
import { task } from "@trigger.dev/sdk/v3";
export const processOrder = task({
id: "process-order",
retry: {
maxAttempts: 3,
factor: 2,
minTimeout: 1000,
},
run: async (payload: { orderId: string }) => {
// Step 1: Charge payment
const payment = await stripe.charges.create({
amount: payload.amount,
source: payload.token,
});
// Step 2: Update inventory (survives crashes between steps)
await db.inventory.decrement(payload.productId);
// Step 3: Send confirmation email
await resend.emails.send({
to: payload.email,
subject: "Order confirmed",
});
return { orderId: payload.orderId, status: "complete" };
},
});The platform checkpoints state between steps. If the inventory update fails, the task retries from that point without re-charging the payment. This is durable execution: the task survives process restarts, redeploys, and infrastructure failures.
Event Routing and Trigger Mechanisms
Tasks can be triggered by:
- HTTP webhooks: External services POST to a generated endpoint
- Scheduled cron: Time-based triggers with no timeout limits
- SDK calls: Trigger from your application code
- Other tasks: Chain tasks together with typed payloads
The routing layer handles deduplication, idempotency, and concurrency control. You can limit how many instances of a task run simultaneously, queue tasks when limits are hit, and fan out work across parallel executions.
For agent workflows, this means you can trigger a task when a user sends a message, have the agent call multiple tools in parallel, wait for external API responses, and resume execution when webhooks arrive. The orchestration layer handles the plumbing.
State Persistence and Retry Semantics
Trigger.dev persists task state in a Postgres database. Each task execution gets a run ID, and the platform tracks:
- Current step in the workflow
- Retry attempt count
- Input payload and intermediate outputs
- Execution logs and traces
When a task fails, the retry policy determines the next attempt. You configure max attempts, backoff factor, and minimum timeout. The platform respects these settings even if your application server crashes between retries.
This matters for agent workflows because LLM calls fail. Rate limits, timeouts, and transient errors are common. A durable retry mechanism means you can write agent logic that assumes eventual success without manually implementing exponential backoff and state recovery.
Observability Surface
The dashboard shows:
- Real-time task execution status
- Step-by-step traces with timing
- Input/output payloads for each run
- Error messages and stack traces
- Retry history and next attempt timing
For debugging agent workflows, this visibility is critical. You can see which tool call failed, inspect the LLM response that triggered the failure, and replay the run with modified inputs. The observability layer is not bolted on; it is part of the execution model.
Deployment Shape
Trigger.dev runs as a hosted service or self-hosted on your infrastructure. The architecture separates:
- Control plane: Manages task definitions, schedules, and run metadata
- Execution plane: Runs your task code in isolated environments
- Storage layer: Postgres for state, S3-compatible storage for logs and artifacts
When you deploy a task, the CLI bundles your code, uploads it to the control plane, and the platform provisions execution capacity. Tasks run in Node.js or Bun runtimes with configurable memory and CPU limits.
For agent workflows, this means you can deploy a task that calls OpenAI, Anthropic, and custom APIs without managing servers, queues, or worker pools. The platform scales execution capacity based on task volume.
Agent Workflow Example: Support Chat with Human Approval
The recent chat agent feature shows how the primitives compose. You define tools (search docs, refund order), mark some as requiring human approval, and the platform pauses execution until approval arrives.
const tools = {
searchDocs: tool({
description: "Search the product docs",
inputSchema: z.object({ query: z.string() }),
execute: async ({ query }) => searchIndex(query),
}),
refundOrder: tool({
description: "Refund an order",
inputSchema: z.object({ orderId: z.string() }),
needsApproval: true, // pauses execution
execute: async ({ orderId }) => payments.refund(orderId),
}),
};
export const supportAgent = chat.agent({
id: "support-agent",
tools,
run: async (messages) => {
// Agent logic runs durably
// Survives refreshes, redeploys, crashes
},
});The task survives page refreshes, server restarts, and infrastructure failures. The agent can search docs, decide a refund is needed, pause for human approval, and resume execution when the approval webhook arrives. The orchestration layer handles state persistence, event routing, and retry logic.
Trade-offs and Failure Modes
| Dimension | Trigger.dev Approach | Trade-off |
|---|---|---|
| Execution model | Durable, checkpointed tasks | Higher latency than in-process queues; not suitable for sub-second response times |
| State persistence | Postgres-backed, survives crashes | Database becomes a bottleneck at high task volume; requires capacity planning |
| Retry semantics | Configurable exponential backoff | Retries consume execution capacity; runaway retries can exhaust quotas |
| Observability | Built-in tracing and logs | Log volume grows with task complexity; requires log retention policies |
| Deployment | Hosted or self-hosted | Hosted service introduces vendor dependency; self-hosted requires operational overhead |
| Language support | TypeScript/JavaScript only | Limits polyglot workflows; Python or Go tasks require separate orchestration |
Failure modes to watch:
- Database contention: High task volume can saturate Postgres connections
- Cold start latency: First execution of a task after deploy incurs initialization overhead
- Retry storms: Misconfigured retry policies can create cascading failures
- Payload size limits: Large inputs or outputs can exceed storage limits
- Webhook delivery: External services must reliably deliver webhooks for event-driven tasks
When Code-First Orchestration Wins
Trigger.dev makes sense when:
- Workflows have complex branching logic that visual builders cannot express
- Tasks need to survive crashes, redeploys, and infrastructure failures
- You want observability and debugging tools integrated with the execution model
- Agent workflows require durable execution across multiple LLM calls and tool invocations
- You prefer writing orchestration logic in TypeScript rather than configuring YAML or JSON
It does not make sense when:
- You need sub-second task execution (use in-process queues instead)
- Workflows are simple enough for visual builders (Zapier, n8n)
- You require polyglot task execution (Python, Go, Rust)
- You want to avoid vendor lock-in for hosted services
- Your team lacks TypeScript expertise
Technical Verdict
Trigger.dev exposes the orchestration primitives that agent workflows need: durable execution, event routing, retry logic, and observability. The code-first approach trades visual simplicity for programmatic flexibility. When an agent needs to call multiple APIs, wait for webhooks, retry on failure, and resume after a crash, these primitives are not optional. They are the plumbing.
The platform is most useful for teams building multi-step agent workflows that span minutes or hours, require human-in-the-loop approvals, and must survive infrastructure failures. It is less useful for simple automations, real-time tasks, or polyglot workflows.
The shift from visual automation builders to code-native orchestration reflects a broader trend: as agents become the automation authors, the tooling must expose programmable primitives rather than drag-and-drop interfaces. Trigger.dev shows what that tooling looks like.