trigger.dev

Trigger.dev provides a TypeScript SDK that allows developers to define long-running tasks as first-class functions with built-in type safety, retry policies, and concurrency controls. Tasks are defined using a fluent API that compiles to a task registry, enabling the framework to understand task signatures, dependencies, and execution requirements at build time rather than runtime. The SDK integrates with the build system to generate type definitions and validate task invocations across the codebase.

Trigger.dev's Run Engine implements a state machine-based execution model where long-running tasks can be paused at checkpoint points, serialized to snapshots, and resumed from the exact point of interruption. The engine uses a Checkpoint System that captures the execution context (local variables, call stack state) and persists it to the database, enabling tasks to survive infrastructure failures, worker crashes, or intentional pauses without losing progress. Execution snapshots are stored in a versioned format that supports resuming across code changes.

Trigger.dev integrates OpenTelemetry for distributed tracing, capturing detailed execution timelines, span data, and performance metrics across task execution. The Observability and Tracing system automatically instruments task execution, worker communication, and database operations, generating traces that can be exported to OpenTelemetry-compatible backends (Jaeger, Datadog, etc.). Traces include task start/end times, checkpoint operations, waitpoint resolutions, and error details, enabling end-to-end visibility into task execution.

Trigger.dev implements a TTL (Time-To-Live) System that automatically expires and cleans up old task runs based on configurable retention policies. The TTL System periodically scans the database for runs that have exceeded their TTL, marks them as expired, and removes associated data (logs, traces, snapshots). This prevents the database from growing unbounded and ensures that sensitive data is automatically deleted after a retention period.

Trigger.dev provides a CLI tool that enables local development and testing of tasks without deploying to the cloud. The CLI starts a local coordinator and worker, allowing developers to trigger tasks from their machine and see execution logs in real-time. The CLI integrates with the build system to automatically recompile tasks when code changes, enabling fast iteration. Local execution uses the same execution engine as production, ensuring that local behavior matches production behavior.

Trigger.dev provides Lifecycle Hooks that allow developers to define initialization and cleanup logic that runs before and after task execution. Hooks are defined declaratively at task definition time and are executed by the Run Engine before task code runs (onStart) and after task code completes (onSuccess, onFailure). Hooks can access task context, perform setup operations (e.g., database connections), and cleanup resources (e.g., close connections, delete temporary files).

Trigger.dev provides a Waitpoint System that allows tasks to pause execution and wait for external events, webhooks, or other task completions without consuming worker resources. Waitpoints are lightweight synchronization primitives that register a task as waiting for a specific condition, then resume execution when that condition is met. The system uses Redis for fast condition checking and the database for persistent waitpoint state, enabling tasks to wait for hours or days without blocking worker threads.

Trigger.dev abstracts worker deployment across multiple infrastructure providers (Docker, Kubernetes, serverless) through a Provider Architecture that implements a common interface for worker lifecycle management. The framework includes Docker Provider and Kubernetes Provider implementations that handle worker provisioning, scaling, and health monitoring. The coordinator service manages worker registration, task assignment, and failure recovery across all providers using a unified queue and dequeue system.

Trigger.dev implements a sophisticated Queue Management system that handles task enqueueing, dequeuing, and worker assignment with support for per-task concurrency limits, rate limiting, and priority-based scheduling. The Enqueue System validates task payloads and assigns tasks to queues based on configuration; the Dequeue System pulls tasks from queues and assigns them to available workers, respecting concurrency constraints. The system uses distributed locking (via Redis) to ensure only one coordinator instance processes a given queue, preventing duplicate task assignment.

Trigger.dev provides a Retry and Error Handling system that automatically retries failed tasks with configurable exponential backoff, jitter, and maximum retry counts. The Run Attempt System tracks each execution attempt, captures error details and stack traces, and determines whether a task should be retried or marked as permanently failed. Retry logic is defined declaratively at task definition time and enforced by the Run Engine, with support for custom retry predicates that determine which errors are retryable.

Trigger.dev provides a web-based dashboard built with Remix and React that displays real-time task execution status, logs, and performance metrics. The dashboard uses WebSocket-based realtime updates to push execution state changes to connected clients, eliminating the need for polling. The Run Monitoring system integrates with OpenTelemetry for distributed tracing, capturing detailed execution timelines, span data, and performance metrics that are visualized in the dashboard.

Trigger.dev exposes an MCP (Model Context Protocol) server that allows AI agents to discover and invoke Trigger.dev tasks as tools. The MCP server implements the standard MCP interface, providing tool definitions, parameter schemas, and execution endpoints that AI models can call. This enables AI agents to trigger background jobs, check task status, and retrieve results through the same interface they use for other tools, integrating Trigger.dev seamlessly into agentic workflows.

Trigger.dev provides a Batch Processing system that allows triggering multiple tasks atomically, ensuring that either all tasks in a batch are enqueued or none are. The batch system uses database transactions to guarantee consistency, preventing partial batch execution if the coordinator crashes mid-batch. Batch operations support conditional triggering, where tasks are only enqueued if certain conditions are met, enabling complex multi-task workflows to be defined declaratively.

Trigger.dev provides an Environment Management system that allows defining separate configurations for development, staging, and production environments. Each environment has its own set of secrets, environment variables, and task configurations that are securely stored and injected into task execution contexts. The system supports environment-specific task behavior, allowing the same task definition to behave differently in different environments (e.g., different API endpoints, retry policies).