Trigger.dev started as a “developer-first Zapier alternative” in February 2023, drawing 745 points and 190 comments on its Show HN post. By October 2023, the team announced V2 as a “Temporal alternative for TypeScript devs,” earning 172 points and 39 comments. That pivot exposes a critical infrastructure gap: event-driven webhooks cannot handle the durability requirements of multi-step agent workflows.
The shift matters because it reveals what breaks when agentic systems outgrow simple trigger infrastructure. Webhooks fire once. Agent tasks retry, wait, branch, and resume across minutes or hours. The plumbing difference is not cosmetic. User feedback from the V1 release drove this architectural pivot, with developers explicitly requesting durable execution over event routing.
What Changed Between V1 and V2
V1 focused on event routing. You connected external services (GitHub, Stripe, Slack) and wrote handlers that ran when events arrived. The execution model assumed short-lived functions that completed in seconds.
V2 introduced durable execution. Tasks can run for hours, survive process restarts, and maintain state across retries. The API surface looks similar (you still write TypeScript functions), but the runtime guarantees changed completely.
Key architectural shifts:
- Execution persistence: Task state survives worker crashes and deploys
- Automatic retries: Configurable backoff without manual error handling
- Long-running support: Tasks can wait for external events or human input
- Step-level granularity: Retries resume from the last completed step, not the start
This is the same problem Temporal solves, but Temporal requires learning Go or Java, understanding workflows vs activities, and running your own cluster or paying for Temporal Cloud.
Durable Execution Without a New Language
Trigger.dev’s bet is that TypeScript developers will accept managed infrastructure if they can avoid learning a new runtime model. The comparison table below positions Temporal as the competitive reference point and webhook-plus-queue as the baseline alternative most teams start with:
| Dimension | Temporal | Trigger.dev V2 | Webhook + Queue |
|---|---|---|---|
| Language | Go, Java, TypeScript (SDK) | TypeScript native | Any |
| State persistence | Event sourcing + history | Managed checkpoints | Manual (Redis/DB) |
| Retry semantics | Workflow-level replay | Step-level resume | Per-message retry |
| Deployment | Self-hosted or cloud | Fully managed | Self-managed |
| Observability | Temporal UI + history | Built-in dashboard | Custom (Datadog, etc.) |
| Learning curve | High (workflows vs activities) | Low (just functions) | Medium (queue semantics) |
The TypeScript-native approach means you write normal async functions. The runtime handles durability by checkpointing state after each await boundary that crosses a durable step.
How Step-Level Checkpointing Works
Trigger.dev wraps your task function and intercepts specific async operations. When you call a durable operation (API request, database write, wait), the runtime:
- Executes the operation
- Persists the result to managed storage
- Continues execution with the result
On retry or resume, the runtime replays the function but returns cached results for completed operations instead of re-executing them. This is conceptually similar to Temporal’s event sourcing but implemented at the TypeScript async boundary level.
The actual implementation uses the task() wrapper from the Trigger.dev SDK. Based on the official documentation and code examples, a research agent workflow looks like this:
// AI agent with tool calling from official docs
export const researchAgent = task({
id: "research-agent",
run: async ({ topic }: { topic: string }) => {
const messages: CoreMessage[] = [
{ role: "user", content: `Research: ${topic}` },
];
for (let i = 0; i < 10; i++) {
const { text, toolCalls, steps } = await generateText({
model: anthropic("claude-opus-4-20250514"),
system: "You are a research assistant with web access.",
messages,
tools: { search, browse, analyze },
maxSteps: 5,
});
if (!toolCalls.length) {
return { summary: text, stepsUsed: steps.length };
}
for (const call of toolCalls) {
const result = await executeTool(call);
messages.push({ role: "tool", content: result });
}
}
},
});If the worker crashes during the loop, the retry resumes from the last completed iteration. Each await boundary creates an implicit checkpoint. The runtime persists the message history and tool call results, so retries do not re-execute completed LLM calls or tool invocations.
State Management and Retry Boundaries
The checkpoint model creates implicit retry boundaries. Each async operation is atomic: it either completes and persists or fails and retries. You cannot partially complete an operation.
This has implications for how you structure agent workflows:
- Idempotent operations: Each step should be safe to retry. If you charge a credit card, do it in a separate task from sending the confirmation email.
- Step granularity: Too coarse (one giant operation) loses durability benefits. Too fine (checkpoint every variable assignment) creates performance overhead.
- External state: Operations that mutate external systems (databases, APIs) need idempotency keys or upsert semantics.
The runtime does not automatically make your code idempotent. It only guarantees that completed operations will not re-execute. You still need to handle partial failures in external systems.
Observability and Debugging
Durable execution creates a natural audit trail. Every operation execution, retry, and state transition gets logged. The Trigger.dev dashboard shows:
- Task execution timeline with operation durations
- Retry history and backoff intervals
- Input/output payloads for each operation
- Live tail of running tasks
This is more structured than parsing application logs but less flexible than full distributed tracing. You cannot inject custom spans or correlate across multiple tasks without additional instrumentation.
The trade-off: you get observability for free, but you work within the platform’s data model. If you need custom metrics or cross-task correlation, you will need to instrument that separately.
Deployment Shape and Scaling
Trigger.dev V2 is fully managed. You write tasks, deploy them via CLI, and the platform handles:
- Worker provisioning and scaling
- State storage and replication
- Retry queue management
- Network ingress and routing
The deployment model is similar to Vercel or Railway: you push code, the platform builds and runs it. You do not configure Kubernetes, manage databases, or tune queue workers.
Scaling happens automatically based on task concurrency and queue depth. You can set concurrency limits per task to control resource usage or rate limit external APIs.
The cost model is usage-based: you pay per task execution and compute time. There is no minimum cluster size or idle cost, but you also cannot optimize infrastructure costs by running your own workers.
Failure Modes and Edge Cases
Durable execution does not eliminate failures. It shifts them:
- Non-idempotent operations: If an operation mutates external state without idempotency, retries can cause duplicate actions (double charges, duplicate emails).
- Long-running waits: Tasks waiting for external events (webhooks, human input) hold state indefinitely. If the event never arrives, you need manual cleanup or timeout logic.
- Checkpoint overhead: Frequent small operations create storage and serialization overhead. The runtime has to persist state after every operation.
- Replay divergence: If your code behavior changes between retries (time-based logic, random values), replayed operations may produce different results than the original execution.
The platform provides timeout configuration and dead-letter queues, but you still need to design for these cases.
When to Use Trigger.dev vs Temporal vs Queues
Use Trigger.dev when:
- You are already writing TypeScript and want to avoid learning Go or Java
- You prefer managed infrastructure over self-hosting
- Your workflows are primarily I/O-bound (API calls, database queries, LLM requests)
- You need durable execution but not sub-second latency
Avoid Trigger.dev when:
- You need multi-language support (Python agents calling Rust tools)
- You require full control over infrastructure and data residency
- Your workflows are CPU-intensive or need custom runtime environments
- You already have Temporal expertise and infrastructure
Use plain queues (SQS, RabbitMQ) when:
- Your tasks are short-lived and stateless
- You already have queue infrastructure and monitoring
- You need fine-grained control over retry logic and dead-letter handling
Use Temporal when:
- You need polyglot workflows (Go orchestrator calling Python workers)
- You require on-premises deployment or air-gapped environments
- Your workflows have complex branching, parallel execution, or saga patterns
- You have the team capacity to operate distributed systems
Technical Verdict
Trigger.dev V2 is a pragmatic choice for TypeScript teams building agent workflows who want durability without operational overhead. The step-level checkpoint model is easier to reason about than Temporal’s workflow replay, and the managed deployment removes infrastructure complexity.
The trade-off is lock-in. You cannot easily migrate to self-hosted infrastructure or switch languages. If your agent system grows to need polyglot workers, custom runtime environments, or on-premises deployment, you will hit the platform’s boundaries.
For early-stage projects and side-hustles, the velocity gain is worth the lock-in risk. For production systems at scale, evaluate whether the managed convenience outweighs the flexibility cost.