Trigger.dev

Column control came to the Trigger.dev runs list. Show, hide, and reorder the columns on any runs list. The part worth the wait is smart columns: pick a value buried in a run and pull it out into its own column. Point a smart column at a run's payload, metadata, or output with a JSON path. $.order.total renders as a number, $.customerId as text, $.status as a badge. It fills in down the whole list, and the live poll keeps the values current as new runs come in. They're display-only by design. A smart column never adds a sort or filter, so nothing touches the ClickHouse sort key or the keyset cursor that keep the runs list fast at scale. You get the value on screen without paying for it in query time. And your whole column layout lives in the URL. A view is just a link: set the columns up for one investigation, bookmark it, and drop it in a thread for a teammate who opens the exact same table. It's live now: https://lnkd.in/ecWrge3P

One secret key per environment always felt too blunt. If a CI job and a background service and a third-party integration all authenticate with the same credential, rotating that key means breaking everything at once. Trigger.dev now supports multiple API keys per environment. Each service, CI job, and integration carries its own credential, and each key is scoped to exactly what it needs. You pick an access preset when you create a key: Trigger only, Task operator, Observer, Operator, Deploy only, Variables only, or no restrictions. Trigger-only and Task-operator keys can be narrowed further to a specific set of tasks (up to 10 identifiers per key), so a key can trigger the two tasks a service owns and nothing else. Keys are independent, which is the part that actually matters. Give a key an expiration date and it stops working automatically once that date passes. Revoke a key and it stops authenticating immediately, with every other key in the environment untouched. No environment-wide rotation. Security stays tight throughout: the full value is shown only once at creation, then hashed at rest, and the dashboard displays only an obfuscated suffix. `trigger deploy` can authenticate with a Deploy-only key, so a deploy credential never carries more access than it needs. Read the changelog: https://lnkd.in/eYyDSyQp

Bulk cancel and replay work from the Trigger.dev SDK, not just the dashboard. Ship a fix, then replay the runs that failed without paging through run IDs or scripting the retries by hand. runs.bulk.replay() and runs.bulk.cancel() take the same filter shape as runs.list() (status, task, tags, queue, version, region) and act on every matching run, from a handful to millions. Kick it off, then runs.bulk.poll() waits for it to finish and returns live counts. runs.bulk.abort() stops one mid-flight. It runs asynchronously, so you can wire it into a deploy script, a scheduled task, or an incident runbook. Changelog: https://lnkd.in/eyaVv22w

When a Trigger.dev task backlog starts building, there's one question worth answering before anything else: is work not starting, or are the runs that start failing? Different problems, different fixes. Now one command tells you which. Run trigger report health and it splits your project into three signals, each with its own verdict and a suggested next action: - Flow: is work starting? (pending counts, start latency, concurrency-limit saturation) - Execution: are the runs that start succeeding? (failure rate and durations vs your normal) - Liveness: is the telemetry itself fresh, so a green board never hides a dead pipe? The verdict is computed server-side from your metrics. There's no model in the diagnosis, so the same inputs always produce the same answer. When flow slows, it walks a cause tree off your queue metrics (env-limit saturation, queue throttling, key starvation, a trigger spike, a dequeue stall), names the likely cause, and rules out the ones that don't fit. You get the same report from the CLI, the get_report MCP tool, and the API. Read the diagnosis instead of correlating dashboards by hand: https://lnkd.in/e8YZy9Sz

Define your prompts in code. Override them live when you need to. On Trigger.dev a prompt lives in code, right next to the task that sends it: an id, a model, a set of variables typed with Zod, and a template. A missing or wrong-typed variable is a compile error, not a broken generation you find in production. Every deploy versions your prompts, so each one keeps a history the dashboard lists with the commit that shipped it. resolve() uses the current deployed version by default, and you can pin a specific version or label when you want to. Need to change the wording or swap the model before the next deploy? Pin an override from the dashboard or the SDK and live calls resolve there until you remove it. It's scoped per environment, so a change in staging doesn't touch production. And because resolve() carries the version, every generation records which prompt version produced it. When an output goes bad, you open the call and see the exact template, and the model that actually ran. Changelog: https://lnkd.in/emc-AhdA

When we launched the Trigger.dev MCP server, it could set up a project, trigger tasks, deploy, and read runs. It does a lot more now. Your coding assistant (Claude Code, Cursor, anything that speaks MCP) can now: Chat with your deployed agents. If you've shipped a chat.agent(), you can list your agents, start a stateful conversation, and send messages from your editor. Testing an agent no longer means building a UI first. Manage prompt versions. List your prompts, inspect versions, promote a new one, or point an environment at a specific version without a redeploy. Pull a health report. get_report returns a server-rendered verdict for an environment: whether work is flowing, whether the runs that start are healthy, and whether your telemetry is fresh. Same answer in chat, on the CLI, or over the API. Plus TRQL queries over your run data, the built-in dashboards, dev-server control, and a --readonly mode that hides every write tool so the assistant can't change anything. The server always runs the latest version, so all of this is already available. Nothing to upgrade.

You could always see what a task did. Now you can see what it spent. Set experimental_telemetry on any Vercel AI SDK call (generateText, streamText, generateObject) and every call becomes a span in the run trace. Nothing to install. Two views on the same data. The dashboard tells you what you spent: cost over time, cost by model, total tokens, and latency across your whole AI workload. The trace tells you why. Open a single call and you get the model, the full message thread, every tool call, and the prompt that produced it. No guessing which of five generateText calls in a task was the expensive one. If you manage prompts with Prompts, spread toAISDKTelemetry() into the call and the span carries the prompt and its version too, so a bad output traces straight back to the prompt that caused it. The AI SDK is just one way to emit those spans. Any span that follows the OpenTelemetry GenAI semantic conventions gets cost data attached and the same observability, whatever produced it. And it's all queryable in TRQL, our SQL-style query language, so "the 10 most expensive tasks over the last 7 days" is one query.

Most AI chat backends run every conversation through one shared server, with a hard timeout on every request. chat.agent gives each conversation its own real machine instead. It boots on the first message and runs for as long as the work takes. The turn is just a task: streamText on the server, useChat on the client, no API route in between. The session outlives the process serving it. Refresh mid-response and the stream replays from where you stopped reading. Close the tab, come back a week later, it’s still there. A turn has no timeout. And a suspended turn (waiting on a human approval, say) isn’t billed, so it can sit open for days for free.

SCIM directory sync is live for orgs on SSO. Assign someone to Trigger.dev in your IdP and they land in your org. Unassign them and their access is gone. Okta, Microsoft Entra, Google Workspace, JumpCloud, OneLogin, and more. https://lnkd.in/e2rRpFT7