Try itExperimental
See what an agent can do with Trigger.dev before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si https://api.trigger.dev/api/v1/projectsrecorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agent workloads — stories about agent workloads in this arenaAgent workloadsevidence →
Stories about agent workloads in this arena
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Developer experience — stories about developer experience in this arenaDeveloper experienceevidence →
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loopevidence →
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debuggingevidence →
Stories about observability debugging in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hostingevidence →
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scaleevidence →
Stories about performance scale in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recoveryevidence →
Stories about reliability recovery in this arena
Triggers scheduling — stories about triggers scheduling in this arenaTriggers schedulingevidence →
Stories about triggers scheduling in this arena
Versioning deployment — stories about versioning deployment in this arenaVersioning deploymentevidence →
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoringevidence →
Stories about workflow authoring in this arena
Story verdicts — every judged story with its evidenceStory verdicts
What’s free: 3 free · 2 paid · 0 enterprise · 33 not stated in evidence
Follow the green: where the map greys out is where Trigger.dev stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agent workloads — stories about agent workloads in this arenaAgent workloads
Stories about agent workloads in this arena
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
✓8/10
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
~5/10
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
✓8/10
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
✓7/10
unlocks → Webhooks · Machine-readable spec · Versioning policy
Subscribe to events via webhooks
—0/10
Build against official SDKs
✓8/10
Issue scoped/least-privilege API credentials for an agent
~6/10
Connect an agent via an official MCP server
✓8/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
!4/10
Test against a sandbox environment without touching production data
~6/10
Explore an interactive API reference with runnable examples
—0/10
Docs for agents
Point an agent at llms.txt or agent-oriented docs
✓8/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
—0/10
Operate the product with natural-language commands
~6/10
Plug MCP servers into this product so it can use their tools
—0/10
Get AI-generated insights and suggestions from my data inside the product
—0/10
Set up automations that run autonomously in the background
✓8/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Developer experience — stories about developer experience in this arenaDeveloper experience
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loop
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debugging
Stories about observability debugging in this arena
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
~4/10
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
~4/10
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
✓8/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hosting
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scale
Stories about performance scale in this arena
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
~6/10
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
~4/10
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
~6/10
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recovery
Stories about reliability recovery in this arena
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
~4/10
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
✓7/10
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
✓7/10
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
✓8/10
Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling
Stories about triggers scheduling in this arena
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
~6/10
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
~3/10
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
~6/10
Versioning deployment — stories about versioning deployment in this arenaVersioning deployment
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring
Stories about workflow authoring in this arena
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
✓8/10
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
~4/10
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
~2/10
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 7/10 | Tprobed | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | fullfree | 8/10 | Xcommunity | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Xcommunity | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Cclaimed | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 6/10 | Tprobed | |
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | disputed | 4/10 | Dcontradicted | |
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | partial | 6/10 | Xcommunity | |
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives C Approvals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 3 | full | 8/10 | Cclaimed | |
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter C Run visibility | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 3 | full | 8/10 | Cclaimed | |
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding C Retries | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | full | 8/10 | Cclaimed | |
I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism C Versioning | platform engineer | Versioning deployment — stories about versioning deployment in this arenaVersioning deployment | 3 | full | 8/10 | Cclaimed | |
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run C Agent loops | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 3 | full | 8/10 | Xcommunity | |
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL C Authoring | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 3 | full | 8/10 | Xcommunity | |
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact C Recovery | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | full | 7/10 | Xcommunity | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | fullfree | 7/10 | Cclaimed | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | partial | 6/10 | Cclaimed | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | partial | 5/10 | Cclaimed | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | none | untested | none yet | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | full | 9/10 | Xcommunity | |
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow C Signals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 2 | full | 8/10 | Cclaimed | |
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes C Streaming | ai-native user | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | full | 8/10 | Xcommunity | |
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute C Long running | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | full | 7/10 | Cclaimed | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | fullfree | 7/10 | Cclaimed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 6/10 | Tprobed | |
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions C Events | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | partial | 6/10 | Xcommunity | |
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest C Flow control | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | partialpaid | 6/10 | Cclaimed | |
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs C Schedules | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | partial | 6/10 | Xcommunity | |
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss C Scaling | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | partialpaid | 6/10 | Xcommunity | |
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code C Ai integrations | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | partial | 5/10 | Cclaimed | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | partial | 5/10 | Cclaimed | |
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination C Composition | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | partial | 4/10 | Cclaimed | |
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover C Replay | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 2 | partial | 4/10 | Cclaimed | |
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending C Exactly once | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | partial | 4/10 | Cclaimed | |
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps C Local dev | backend developer | Developer experience — stories about developer experience in this arenaDeveloper experience | 2 | partial | 4/10 | Tprobed | |
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs C Language coverage | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | partial | 2/10 | Cclaimed | |
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | 0/10 | ||
I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network C Deployment model | platform engineer | Operations hosting — stories about operations hosting in this arenaOperations hosting | 2 | none | 0/10 | ||
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | 0/10 | ||
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave C Metrics | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 1 | partial | 4/10 | Tprobed | |
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue C Prioritization | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 1 | partial | 4/10 | Cclaimed | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | partial | 4/10 | Cclaimed | |
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want C Flow shaping | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 1 | partial | 3/10 | Cclaimed |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 32 stories with headroom
What would move Trigger.dev’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productDelegate tasks to a built-in AI assistant inside the product
nonemoves Built-in AIimpact 45
Trigger.dev provides infrastructure (tasks, MCP server, agent skills) to help users BUILD AI agents/chat assistants and lets external AI coding tools (Claude Code, Cursor) connect via MCP, but there is no evidence of a built-in AI assistant embedded inside the Trigger.dev product itself that a user can delegate tasks to.
Agenticness — how well agents can access and operate the productPlug MCP servers into this product so it can use their tools
nonemoves agent-readyimpact 45
Trigger.dev documents an official MCP *server* that lets external AI coding tools (Claude Code, Cursor, Windsurf) call into Trigger.dev projects — the reverse direction from this story.
Privacy posture — data-handling and privacy storiesPrevent my data from being used to train AI models
nonemoves PA Scoreimpact 30
Missing: any explicit data-training opt-out policy, AI model training disclosure, or contractual language on this topic.
Agenticness — how well agents can access and operate the productGet AI-generated insights and suggestions from my data inside the product
nonemoves Built-in AIimpact 30
Trigger.dev's evidence shows infrastructure for building AI agents/tasks and an MCP server letting external AI assistants interact with the platform, but there is no evidence the product itself surfaces AI-generated insights or suggestions from a user's run/data dashboard (e.g., anomaly detection, usage recommendations, auto-summaries of traces).
Agenticness — how well agents can access and operate the productSubscribe to events via webhooks
nonemoves agent-readyimpact 30
The evidence shows Trigger.dev can send outbound webhook alerts when tasks fail (docs-29) and supports many trigger types (scheduled, API calls, waitpoint tokens), but there is no documentation of an inbound webhook subscription mechanism that lets a task be triggered by external events via webhooks.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
Trigger.dev docs contain static code snippets (e.g.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
A direct probe found no OpenAPI/Swagger spec at any standard location (all 404s), and no documentation references a downloadable machine-readable API spec despite an SDK/management API existing.
Operations hosting — stories about operations hosting in this arenaI run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
nonemoves PA Scoreimpact 20
Evidence shows only two deployment modes: fully managed cloud (trigger.dev Cloud) and fully self-hosted (docs-17, run and manage the entire platform yourself).
Showing the top 8 of 32 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map12 surfaces · 42 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
docs41 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
- Point an agent at llms.txt or agent-oriented docs
- Run the product headlessly / in CI for automation
- Connect an agent via an official MCP server
- Use an official CLI
- Drive the product through a documented public API
- Build against official SDKs
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- Test against a sandbox environment without touching production data
- Rely on versioned APIs with a documented deprecation policy
- Perform bulk operations across many items at once
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- Version, review, and roll back my automations
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Do everything through the API that I can do in the UI
- Export all of my data in open formats and leave
- Read the product's source under an open license
- Self-host the core product
- I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
- I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
- I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Product docs17 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
- Set up automations that run autonomously in the background
- Perform bulk operations across many items at once
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Do everything through the API that I can do in the UI
- I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
- I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
Hacker News14 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
- Run the product headlessly / in CI for automation
- Build against official SDKs
- Set up automations that run autonomously in the background
- Test against a sandbox environment without touching production data
- Rely on versioned APIs with a documented deprecation policy
- Schedule recurring jobs or workflows
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
GitHub README13 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- Run the product headlessly / in CI for automation
- Build against official SDKs
- Set up automations that run autonomously in the background
- Define rules that trigger actions automatically on events
- Export all of my data in open formats and leave
- Read the product's source under an open license
- Self-host the core product
- Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
trigger.dev6 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- Define rules that trigger actions automatically on events
- A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
Vs docs5 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
OpenAPI spec4 stories
Llms full docs4 stories
- Point an agent at llms.txt or agent-oriented docs
- Build against official SDKs
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Blog docs3 stories
Changelog docs1 story
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -si https://api.trigger.dev/api/v1/projectsreproduced$ curl -si https://api.trigger.dev/api/v1/projects
HTTP/2 401
date: Thu, 10 Sep 2026 18:41:12 GMT
content-type: application/problem+json; charset=utf-8
content-length: 215
strict-transport-security: max-age=3153600000
x-robots-tag: noindex, nofollow
etag: W/"d7-Ea1kXLuJvMfV6g99wiHz5SuKFyM"
{
"title": "Unauthorized",
"status": 401,
"type": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401",
"detail": "No authorization header provided",
"error": "No authorization header provided"
}
$npx -y trigger.dev@latest --versionreproduced$ npx -y trigger.dev@latest --version 4.5.16
$echo '<jsonrpc initialize>' | npx -y trigger.dev@latest mcpreproduced$ echo '<jsonrpc initialize>' | npx -y trigger.dev@latest mcp
\|/-\|(node:43346) ExperimentalWarning: localStorage is not available because --localstorage-file was not provided.
(Use `node --trace-warnings ...` to show where the warning was created)
{"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true}},"serverInfo":{"name":"trigger","version":"4.5.16"},"instructions":"Trigger.dev MCP server to automate your Trigger.dev projects and answer questions about Trigger.dev by searching the docs. \nIf you need help setting up Trigger.dev in your project please refer to https://trigger.dev/docs/manual-setup. \nIf the user asks for help with adding Trigger.dev to their project, please refer to https://trigger.dev/docs/manual-setup.\n "},"jsonrpc":"2.0","id":1}
\
$curl -s https://trigger.dev/docs/llms.txt | head -6reproduced$ curl -s https://trigger.dev/docs/llms.txt | head -6 # Trigger.dev > Trigger.dev is an open source background jobs framework that lets you write reliable workflows in plain async code. Run long-running AI tasks, handle complex background jobs, and build AI agents with built-in queuing, automatic retries, and real-time monitoring. No timeouts, elastic scaling, and zero infrastructure management required. - [Welcome to the Trigger.dev docs](https://trigger.dev/docs/introduction.md): Find all the resources and guides you need to get started - [Quick start: add Trigger.dev to your project](https://trigger.dev/docs/quick-start.md): Set up Trigger.dev in your existing project in under 3 minutes. Install the SDK, create your first background task, and trigger it from your code.
$curl -sL https://trigger.dev/docs/how-it-works.md | head -8reproduced$ curl -sL https://trigger.dev/docs/how-it-works.md | head -8 > ## Documentation Index > Fetch the complete documentation index at: https://trigger.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # How Trigger.dev works > Understand how Trigger.dev works and how it can help you.
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
10 of 20 testable claims verified · 0 contradicted → integrity 50/100
27 distinct capability claims found in Trigger.dev’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
10
Verified
10
Unverified
0
Contradicted
21
Undersold
Verified (12)
“Write workflows as plain async code in your own language”
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSLfullproof ↗
“Elastic scaling of workers to handle load”
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker losspartialproof ↗
“Scheduled tasks run recurringly using cron syntax”
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runspartialproof ↗
“Live run updates and data streaming to frontend/backend without polling”
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executesfullproof ↗
“Official MCP server lets AI assistants interact directly with your Trigger.dev projects”
“MCP server exposes tools for conversing with chat agents from Claude Code, Cursor, Windsurf, etc.”
“Durable multi-turn AI chat tasks survive refreshes, deploys, and crashes”
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
“Installable agent skills teach AI coding assistants to write tasks, realtime frontends, and chat agents”
Point an agent at llms.txt or agent-oriented docsfullproof ↗
“Official CLI supports local development, self-hosting, and deployment”
“GitHub Action workflow automatically deploys tasks on push to main”
Run the product headlessly / in CI for automationfullproof ↗
“SDK method lets you list runs filtered by status programmatically”
“Durable tasks, retries, queues, and idempotency are provided as building blocks for reliable agents”
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
Unverified (14)
“Open source framework for background jobs/workflows”
“Tasks can run long without hitting timeouts”
A workflow can sleep or wait for days to months without holding a server, connection, or billable computefullproof ↗
“Runs list supports custom, reorderable columns and smart columns extracted via JSON path”
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filterfullproof ↗
“Triggering a task returns a handle you can use to check status, cancel, or retry it”
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflowfullproof ↗
“Tasks can be configured to retry automatically with exponential backoff”
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffoldingfullproof ↗
“Waitpoint tokens pause a run until an external event/approval completes it”
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrivesfullproof ↗
“Once a run starts it's locked to that code version, unaffected by later deploys”
I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinismfullproof ↗
“Concurrency limit can be set per task queue to cap simultaneous executions”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restpartialproof ↗
“Dashboard shows real-time view of current limits, quotas, and rate-limit usage”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restpartialproof ↗
“Runs progress through tracked lifecycle states (pending, delayed, queued, dequeued, executing)”
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filterfullproof ↗
“Self-hosting lets you run the platform on your own infrastructure with full control”
“Extra concurrency capacity can be purchased beyond the Pro tier limit”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restpartialproof ↗
“Idempotency support helps prevent duplicate actions in agent workflows”
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sendingpartialproof ↗
“Agent tool calls can require human approval, keeping the run alive until approved”
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrivesfullproof ↗
Undersold (21)
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue codepartialproof ↗
Drive the product through a documented public APIfullproof ↗
Issue scoped/least-privilege API credentials for an agentpartialproof ↗
Set up automations that run autonomously in the backgroundfullproof ↗
Operate the product with natural-language commandspartialproof ↗
Test against a sandbox environment without touching production datapartialproof ↗
Perform bulk operations across many items at oncepartialproof ↗
Define rules that trigger actions automatically on eventspartialproof ↗
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked stepspartialproof ↗
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehavepartialproof ↗
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recoverpartialproof ↗
Do everything through the API that I can do in the UIpartialproof ↗
Export all of my data in open formats and leavepartialproof ↗
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queuepartialproof ↗
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intactfullproof ↗
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functionspartialproof ↗
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually wantpartialproof ↗
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordinationpartialproof ↗
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKspartialproof ↗
Claims outside our story set (1)
Real capability claims found in Trigger.dev’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Accounts can enable Multi-Factor Authentication for extra security”
source ↗
Business model
Free $5 credits/mo, 20 concurrent runs; Hobby $10/mo, Pro $50/mo with included credits; compute billed per second plus $0.25/10K runs; Apache-2.0 self-host free; Enterprise custom.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
Agent surface uptime llms.txt up (tracking since Sep 11 '26)