Orchestrate Background Jobs and AI Workflows

Covers building reliable background jobs, AI workflows, and scheduled or batch tasks on Trigger.dev, a TypeScript-first async execution platform, anchored on eight principles: tasks are independently retryable, runs are durable across crashes, integrations are first-class SDK wrappers, log liberally for debugging, concurrency limits protect downstream resources, delays and schedules are built in with no external cron needed, AI-ready by design, and local dev matches production via the CLI. Five worked patterns cover the core surface: basic task setup with configurable retry backoff (maxAttempts, exponential factor); an AI task using the built-in @trigger.dev/openai wrapper for automatic retries; a schedules.task() with cron syntax for periodic jobs; batch processing with a queue.concurrencyLimit and wait.for() rate-limiting between items, fanning out via Promise.all of .trigger() calls; and a webhook handler using idempotencyKeys.create() to deduplicate events, such as Stripe webhooks, before processing.

npx trigger.dev@latest env push

Use it for background jobs, AI processing pipelines, scheduled or cron tasks, webhook handlers, and batch data processing on Trigger.dev specifically - not for Redis-backed queues (routed to a bullmq-specialist skill), serverless HTTP-delivered queues without a worker runtime (upstash-qstash), pure event-driven or fan-out architectures (inngest), workflow orchestration (temporal-craftsman), or general infrastructure (infra-architect). It documents ten sharp edges, three at CRITICAL severity: a task timeout silently kills execution with no clear error, mitigated by logging progress at each step and sizing the machine.preset; a non-serializable payload - a Date, a class instance, a circular reference - silently loses data or throws once JSON-serialized, so always pass ISO strings and plain objects; and environment variables configured in Vercel or Railway do not automatically sync to Trigger.dev's separate cloud runtime and must be pushed via the dashboard or env push. Seven more at HIGH/MEDIUM: SDK/CLI version mismatches break task registration, retries re-run side effects from the beginning causing duplicate emails or charges without an idempotency key, unbounded concurrency overwhelms rate-limited downstream APIs, trigger.config.ts must sit at the package root rather than the monorepo root, wait.for() inside a per-item loop bloats task checkpoint state until it hits memory limits, using a raw SDK instead of Trigger.dev's wrapped integrations forfeits automatic retries and rate-limit handling, and triggering a task with no local dev server running silently drops it.

Inputs are a task's typed payload, which must be JSON-serializable, and optional queue/retry config; outputs are the task's return value plus dashboard-visible logs, retry attempts, and run state. Ten automated validation checks flag common defects at ERROR/WARNING/CRITICAL severity: a task missing an explicit id, missing logging, missing error handling, missing a concurrency limit, a Date or class instance in the trigger payload, a hardcoded Trigger.dev API key (use TRIGGER_SECRET_KEY), raw OpenAI or Anthropic SDK usage instead of the wrapped integration, and wait.for inside a loop.

Ships first-party integrations for OpenAI, Anthropic, Resend, Stripe, Slack, and Supabase, and supports Next.js, Remix, Express, and Hono; deployment targets are Trigger.dev Cloud, self-hosted, or Docker. It defines four multi-skill workflows: AI Background Processing (nextjs-app-router triggers, trigger-dev queues, llm-architect processes, supabase-backend stores results), Webhook Processing Pipeline (stripe-integration receives, trigger-dev processes, supabase-backend updates, email-systems notifies), Batch Data Processing, and Scheduled Reports - and hands off to bullmq-specialist, upstash-qstash, inngest, and temporal-craftsman for architectures it doesn't cover.

Developers building reliable async background jobs, AI pipelines, scheduled tasks, or webhook processors in TypeScript who want Trigger.dev's durable-run and built-in-integration model, plus its specific serialization, concurrency, and environment-sync gotchas, rather than hand-rolling retry and queue logic.