@trigger.dev/sdk 4.7.3 → 4.7.5

package/docs/github-actions.mdx

@@ -47,7 +47,7 @@ jobs:
         env:
           TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
         run: |
-          npx trigger.dev@latest deploy --external-id ${{ github.sha }}
+          npx trigger.dev@latest deploy --env prod --external-id ${{ github.sha }}
 ```
 
 ```yaml .github/workflows/release-trigger-staging.yml
@@ -184,7 +184,7 @@ Tip: add the `trigger.dev` CLI to your `devDependencies` and the deploy command
 ```json
 {
   "scripts": {
-    "deploy:trigger-prod": "trigger deploy",
+    "deploy:trigger-prod": "trigger deploy --env prod",
     "deploy:trigger": "trigger deploy --env staging"
   },
   "devDependencies": {
@@ -254,7 +254,7 @@ jobs:
           TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
           TRIGGER_API_URL: ${{ secrets.TRIGGER_API_URL }}
         run: |
-          npx trigger.dev@latest deploy
+          npx trigger.dev@latest deploy --env prod
 ```
 
 </CodeGroup>

package/docs/how-it-works.mdx

@@ -6,7 +6,7 @@ description: "Understand how Trigger.dev works and how it can help you."
 
 ## Introduction
 
-Trigger.dev v3 allows you to integrate long-running async tasks into your application and run them in the background. This allows you to offload tasks that take a long time to complete, such as sending multi-day email campaigns, processing videos, or running long chains of AI tasks.
+Trigger.dev allows you to integrate long-running async tasks into your application and run them in the background. This allows you to offload tasks that take a long time to complete, such as sending multi-day email campaigns, processing videos, or running long chains of AI tasks.
 
 For example, the below task processes a video with `ffmpeg` and sends the results to an s3 bucket, then updates a database with the results and sends an email to the user.
 
@@ -278,8 +278,8 @@ export const convertVideo = task({
     // Update database
     await updateVideoUrl(videoId, s3Url);
 
-    // Send email, we don't need to wait for this to finish
-    await sendUserEmail.trigger({ videoId, s3Url }, { idempotencyKey });
+    // Send email
+    await sendUserEmail.triggerAndWait({ videoId, s3Url }, { idempotencyKey }).unwrap();
 
     return { success: true, s3Url };
   },
@@ -420,7 +420,7 @@ When you run `npx trigger.dev@latest dev`, we run your task code locally on your
 - Changes are automatically detected and a new version is spun up when you save your code.
 - Add debuggers and breakpoints to your code and debug it locally.
 - Each task is run in a separate process, so you can run multiple tasks in parallel.
-- Auto-cancels tasks when you stop the dev server.
+- Stopping the dev server stops your local task processes. If the CLI is killed abruptly (for example by a package manager sending SIGKILL), in-flight runs are cancelled automatically. After a normal Ctrl-C stop, in-flight runs are not cancelled and can end with a `TASK_RUN_STALLED_EXECUTING` error once the 5 minute heartbeat timeout passes.
 
 <Note>
   Trigger.dev currently does not support "offline" dev mode, where you can run tasks without an
@@ -430,7 +430,7 @@ When you run `npx trigger.dev@latest dev`, we run your task code locally on your
 
 ## Staging and production environments
 
-Trigger.dev supports deploying to `prod` and `staging` environments. This allows you to test your tasks in a staging environment before deploying them to production. You can deploy to a different environment by running `npx trigger.dev@latest deploy --env <env>`, where `<env>` is either `prod` or `staging`. Each environment has its own API Key, which you can use to trigger tasks in that environment.
+Trigger.dev supports deploying to `prod` and `staging` environments. This allows you to test your tasks in a staging environment before deploying them to production. You can deploy to a different environment by running `npx trigger.dev@latest deploy --env <env>`, where `<env>` is `prod`, `staging` or `preview` (the branch is detected from git, or you can pass `--branch`). Each environment has its own API Key, which you can use to trigger tasks in that environment.
 
 For additional isolated environments, you can use [preview branches](/deployment/preview-branches), which allow you to create separate environments for each branch of your code.
 

package/docs/introduction.mdx

@@ -5,6 +5,8 @@ description: "Build and run durable AI agents and workflows in TypeScript. Long-
 mode: "center"
 ---
 
+import AgentSetupPrompt from "/snippets/agent-setup-prompt.mdx";
+
 <CardGroup cols={2}>
   <Card title="Quick start" icon="rocket" href="/quick-start" color="#A8FF53">
     Go from zero to your first task in 3 minutes.
@@ -20,6 +22,10 @@ mode: "center"
   </Card>
 </CardGroup>
 
+## Set up with AI
+
+<AgentSetupPrompt />
+
 ## What is Trigger.dev?
 
 Trigger.dev is the open source platform for building and running durable AI agents and workflows in TypeScript. Run them for hours, configure automatic retries, control concurrency, and manage queues. There's no execution timeout, and no queue or worker infrastructure for you to build.

package/docs/limits.mdx

@@ -12,6 +12,12 @@ You can view your current limits, quotas, and rate limit usage in real-time by v
   [Billing limits and alerts](/billing-limits).
 </Note>
 
+## Run duration
+
+Runs have no maximum duration. You set a default `maxDuration` for your project and can override it per task or per run, or set it to `timeout.None` to let a run execute indefinitely.
+
+Trigger is built for long running AI agents and workflows and we have seen Trigger.dev users with runs lasting more than six months.
+
 ## Concurrency limits
 
 Concurrency is allocated **per environment**, not as a single figure for the whole organization. Each plan sets a separate default for production, staging, preview and development:
@@ -43,7 +49,7 @@ You can request a higher rate limit from us if you're on a paid plan.
 The maximum number of runs that can be queued **per queue** (not across all queues in the environment). Each queue can hold up to its limit independently. When a queue hits its limit, new triggers to that queue are rejected.
 
 <Note>
-  The limits below apply to [Trigger.dev Cloud](https://trigger.dev). If you self-host Trigger.dev, queue size limits are configurable via the `MAXIMUM_DEV_QUEUE_SIZE` and `MAXIMUM_DEPLOYED_QUEUE_SIZE` environment variables — see [Self-hosting environment variables](/self-hosting/env/webapp#run-engine).
+  The limits below apply to [Trigger.dev Cloud](https://trigger.dev). If you self-host Trigger.dev, queue size limits are configurable via the `MAXIMUM_DEV_QUEUE_SIZE` and `MAXIMUM_DEPLOYED_QUEUE_SIZE` environment variables — see [Self-hosting environment variables](/self-hosting/env/webapp).
 </Note>
 
 | Pricing tier | Development (per queue) | Staging / Production (per queue) |
@@ -60,7 +66,7 @@ On Trigger.dev Cloud, all runs have an enforced maximum TTL of 14 days. Runs wit
 
 There is no maximum on `delay`.
 
-If you self-host, you can configure a maximum TTL via the `RUN_ENGINE_DEFAULT_MAX_TTL` environment variable — see [Self-hosting environment variables](/self-hosting/env/webapp#run-engine).
+If you self-host, you can configure a maximum TTL via the `RUN_ENGINE_DEFAULT_MAX_TTL` environment variable — see [Self-hosting environment variables](/self-hosting/env/webapp).
 
 ## Schedules
 
@@ -124,8 +130,6 @@ Payloads and outputs over 512KB are kept in object storage rather than inline. C
 
 A single batch can have a maximum of 1,000 items with SDK 4.3.1+. Prior versions are limited to 500 items.
 
-<SoftLimit />
-
 ## Batch trigger rate limits
 
 Batch triggering uses a token bucket algorithm to rate limit the number of runs you can trigger per environment. Each run in a batch consumes one token.
@@ -154,6 +158,26 @@ When you send a batch trigger, we convert it into individual runs. This limit co
 | Hobby        | 10 concurrent batches |
 | Pro          | 50 concurrent batches |
 
+## Webhook ingest rate limits
+
+Each hosted webhook endpoint accepts a limited number of requests per 10 seconds. Requests over the limit get a `429` response with a `Retry-After` header, and providers that retry deliver them again after the window.
+
+| Pricing tier | Requests per endpoint |
+| :----------- | :-------------------- |
+| Free         | 100 every 10 sec      |
+| Hobby        | 300 every 10 sec      |
+| Pro          | 1,000 every 10 sec    |
+| Enterprise   | Set per organization  |
+
+All of an environment's endpoints also share a per-environment limit, counted in tokens: a request costs one token for every 64 KiB of body, started, so a 10 KiB event costs one and a 1 MiB event costs 16. Requests over it get the same `429` with `Retry-After`.
+
+| Pricing tier | Tokens per environment |
+| :----------- | :--------------------- |
+| Free         | 300 every 10 sec       |
+| Hobby        | 1,000 every 10 sec     |
+| Pro          | 3,000 every 10 sec     |
+| Enterprise   | Set per organization   |
+
 ## Log retention
 
 | Pricing tier | Limit   |
@@ -170,8 +194,8 @@ We limit the size of logs to prevent oversized data potentially causing issues.
 
 #### Attribute Limits
 
-- Span Attribute Count Limit: 256
-- Log Attribute Count Limit: 256
+- Span Attribute Count Limit: 1024
+- Log Attribute Count Limit: 1024
 - Span Attribute Value Length Limit: 131072 characters
 - Log Attribute Value Length Limit: 131072 characters
 
@@ -188,8 +212,8 @@ We limit the size of logs to prevent oversized data potentially causing issues.
 
 #### Attribute Clipping Behavior
 
-- Attributes exceeding the value length limit (1028 characters) are discarded.
-- If the total number of attributes exceeds 256, additional attributes are not included.
+- Attributes exceeding the value length limit (131072 characters) are discarded.
+- If the total number of attributes exceeds 1024, additional attributes are not included.
 
 #### Attribute Value Size Calculation
 

package/docs/logging.mdx

@@ -159,7 +159,7 @@ Trigger.dev automatically collects the following metrics for deployed tasks. No
 | `nodejs.heap.total` | gauge | bytes | V8 heap total |
 
 <Note>
-In dev mode (`trigger dev`), only `process.*` and custom metrics are available.
+In dev mode (`trigger dev`), the `process.*` and `nodejs.*` metrics above are collected, along with custom metrics.
 </Note>
 
 ### Context attributes

package/docs/machines.mdx

@@ -11,7 +11,7 @@ import { task } from "@trigger.dev/sdk";
 export const heavyTask = task({
   id: "heavy-task",
   machine: "large-1x",
-  run: async ({ payload, ctx }) => {
+  run: async (payload, { ctx }) => {
     //...
   },
 });

package/docs/manual-setup.mdx

@@ -109,7 +109,7 @@ Then add scripts to your `package.json`:
 {
   "scripts": {
     "dev:trigger": "trigger dev",
-    "deploy:trigger": "trigger deploy"
+    "deploy:trigger": "trigger deploy --env prod"
   }
 }
 ```

package/docs/mcp-introduction.mdx

@@ -299,7 +299,7 @@ After adding the config, restart your client. You should see a server named **tr
 
 ## Authentication
 
-The `search_docs` tool works without authentication. All other tools require you to be logged in via the [Trigger.dev CLI](/cli-login-commands). The first time you use an authenticated tool, your MCP client will prompt you to log in.
+The `search_docs` tool works without authentication, and so do the local-only tools `list_profiles`, `dev_server_status` and `stop_dev_server`. All other tools require you to be logged in via the [Trigger.dev CLI](/cli-login-commands). The first time you use an authenticated tool, your MCP client will prompt you to log in.
 
 <Accordion title="CLI Options">
 
@@ -310,7 +310,6 @@ The `install-mcp` command supports these options:
 - `-p, --project-ref <project ref>` — Scope the MCP server to a specific project
 - `-t, --tag <package tag>` — CLI package version to use (default: latest)
 - `--dev-only` — Restrict to the dev environment only
-- `--readonly` — Read-only mode. Hides write tools (`deploy`, `trigger_task`, `cancel_run`) so the AI cannot make changes to your account
 - `--yolo` — Install into all supported clients automatically
 - `--scope <scope>` — `user`, `project`, or `local`
 - `--client <clients...>` — Install into specific client(s)
@@ -341,17 +340,19 @@ Restrict to dev environment for a specific project:
 npx trigger.dev@latest install-mcp --dev-only --project-ref proj_abc123
 ```
 
-Read-only mode (prevents AI from deploying or triggering tasks):
+To add these options to a manual config, append them to the `args` array:
 
-```bash
-npx trigger.dev@latest install-mcp --readonly
+```json
+{
+  "args": ["trigger.dev@latest", "mcp", "--dev-only", "--project-ref", "proj_abc123"]
+}
 ```
 
-To add these options to a manual config, append them to the `args` array:
+The `mcp` command also accepts `--readonly`, which hides the tools that write to your account (for example `deploy`, `trigger_task` and `cancel_run`) so the AI cannot make changes to it. It is only available as a manual config arg:
 
 ```json
 {
-  "args": ["trigger.dev@latest", "mcp", "--dev-only", "--project-ref", "proj_abc123"]
+  "args": ["trigger.dev@latest", "mcp", "--readonly"]
 }
 ```
 

package/docs/mcp-tools.mdx

@@ -4,6 +4,8 @@ sidebarTitle: "Tools"
 description: "Learn about how to use the tools available in the Trigger.dev MCP Server"
 ---
 
+import WebhooksBetaNote from "/snippets/webhooks-beta-note.mdx";
+
 ## Documentation and Search Tools
 
 ### search_docs
@@ -102,6 +104,20 @@ Cancel a running or queued run.
 - `"Cancel run run_abc123"`
 - `"Stop that task"`
 
+### replay_run
+
+Replay a run as a new run of the same task, in the same environment. The new run reuses the original run's payload, metadata, tags, queue, concurrency key, and machine unless you override them. See [Replaying](/replaying) for how each option falls back.
+
+**Parameters:**
+- `runId` (required): The run to replay, starting with `run_`
+- `payload`, `metadata`, `tags` (optional): Replace the original run's values
+- `queue`, `concurrencyKey`, `machine`, `version`, `region`, `delay`, `ttl`, `idempotencyKey`, `maxAttempts`, `maxDuration`, `priority` (optional): Override the trigger options for the new run
+
+**Example usage:**
+- `"Replay run run_abc123"`
+- `"Replay that failed run with userId set to user_456"`
+- `"Replay run run_abc123 on a large-1x machine in 10 minutes"`
+
 ## Deployment Tools
 
 ### deploy
@@ -175,7 +191,7 @@ Execute a TRQL query against your Trigger.dev data. TRQL is a SQL-style query la
 
 ### list_dashboards
 
-List available built-in dashboards with their widgets. Each dashboard contains pre-built queries for common metrics.
+List the built-in dashboards and your organization's custom dashboards, with their widgets.
 
 **Example usage:**
 - `"What dashboards are available?"`
@@ -183,12 +199,28 @@ List available built-in dashboards with their widgets. Each dashboard contains p
 
 ### run_dashboard_query
 
-Execute a single widget query from a built-in dashboard. Use `list_dashboards` first to see available dashboards and widget IDs.
+Execute a single widget query from a built-in or custom dashboard. Use `list_dashboards` first to see available dashboards and widget IDs.
 
 **Example usage:**
 - `"Run the total runs widget from the overview dashboard"`
 - `"Show me the LLM cost over time from the AI dashboard"`
 
+### create_dashboard
+
+Create a custom dashboard, optionally with widgets. Each widget has a title, a TRQL query and a display: a table, a bar or line chart, a big number, or a section title. Queries are checked when the dashboard is saved.
+
+**Example usage:**
+- `"Make a dashboard for the email tasks with total runs, failures and runs per day"`
+- `"Create a dashboard that charts p95 duration by task"`
+
+### set_dashboard_widgets
+
+Replace every widget on a custom dashboard, and optionally rename it.
+
+**Example usage:**
+- `"Add a failed runs widget to the email dashboard"`
+- `"Change the runs per day chart to a line chart"`
+
 ### get_report
 
 Render an interpreted [health report](/reports) — a deterministic verdict, not a raw panel — as text with sparklines. The `health` report answers whether work is flowing, whether the runs that start are healthy, and whether the telemetry is fresh, with a headline verdict and a suggested next action. Returns markdown by default, or ANSI when `color` is set. Read-only.
@@ -225,7 +257,7 @@ Check the status of the dev server and view recent output. Shows whether it is s
 - `"Are there any build errors?"`
 
 <Callout type="warning">
-  The deploy and list_preview_branches tools are not available when the MCP server is running with the `--dev-only` flag. The `--readonly` flag hides deploy, trigger_task, and cancel_run.
+  The deploy and list_preview_branches tools are not available when the MCP server is running with the `--dev-only` flag. The `--readonly` flag hides deploy, trigger_task, cancel_run, replay_run, create_dashboard, and set_dashboard_widgets.
 </Callout>
 
 ## Agent Chat Tools
@@ -317,3 +349,81 @@ Append one record to a named side channel's `in` stream. Sends control input to
 <Callout type="warning">
   `write_session_channel` is a write operation and is not available in readonly mode.
 </Callout>
+
+## Webhook Tools
+
+<WebhooksBetaNote />
+
+Set up and debug [hosted webhook endpoints](/webhooks/overview). Endpoint ids start with `wh_` and delivery ids with `whd_`; endpoint tools also accept an endpoint's declared id. The same operations are on the [Webhooks API](/management/webhooks/list-endpoints).
+
+### list_webhook_endpoints
+
+List the environment's webhook endpoints: each one's id, declared id, source, status, URL and whether its signing secret is set.
+
+**Example usage:**
+- `"Which webhook endpoints do I have in dev?"`
+
+### get_webhook_endpoint_details
+
+Get an endpoint's subscribers, with the filters that decide which events each accepts, and its setup prompt: the steps for registering the endpoint and its signing secret with the provider.
+
+**Parameters:**
+- `endpointId` (required): the endpoint's declared id (such as `payments`) or `wh_` id
+
+**Example usage:**
+- `"Connect my payments webhook to Stripe"`
+
+### list_webhook_deliveries
+
+List recent deliveries, newest first.
+
+**Parameters:**
+- `endpointId` (optional): only this endpoint's deliveries, by declared id or `wh_` id
+- `status` (optional): only these statuses, such as `["failed", "filtered"]`
+- `period` (optional, default: `7d`): how far back to look
+- `limit` (optional, default: `20`): how many to return, up to 100
+- `cursor` (optional): the cursor from a previous call, for the next page
+
+**Example usage:**
+- `"Did the Stripe checkout event arrive in the last hour?"`
+- `"Show me failed deliveries on the github endpoint"`
+
+### get_webhook_delivery
+
+Get one delivery: its status and error, each subscriber's result (the run or session it started, or why its filter skipped the event), how many waiting runs it resumed, and its event and headers.
+
+**Parameters:**
+- `deliveryId` (required): the delivery's `whd_` id
+
+**Example usage:**
+- `"Why didn't this webhook trigger my order task?"`
+
+### replay_webhook_delivery
+
+Replay a delivery from its stored event. Without `targetId` it goes to every subscriber again, with their filters checked again. With `targetId` it goes to that subscriber even if its filter skipped the event.
+
+**Parameters:**
+- `deliveryId` (required): the delivery's `whd_` id
+- `targetId` (optional): the subscriber id to replay to
+
+**Example usage:**
+- `"Replay that delivery to the refunds task"`
+
+### generate_webhook_secret
+
+Generate a new signing secret for an endpoint and return it once, for providers where you choose the secret (such as GitHub). It replaces any existing secret.
+
+**Parameters:**
+- `endpointId` (required): the endpoint's declared id (such as `payments`) or `wh_` id
+
+### set_webhook_secret
+
+Store a signing secret or public key the provider issued, such as Stripe's `whsec_` secret. It replaces any existing secret.
+
+**Parameters:**
+- `endpointId` (required): the endpoint's declared id (such as `payments`) or `wh_` id
+- `secret` (required): the secret or public key
+
+<Callout type="warning">
+  `replay_webhook_delivery`, `generate_webhook_secret` and `set_webhook_secret` are write operations and are not available in readonly mode.
+</Callout>

package/docs/migrating-from-v3.mdx

@@ -248,7 +248,7 @@ import { task } from "@trigger.dev/sdk";
 
 export const myTask = task({
   id: "my-task",
-  onStart: ({ payload, ctx }) => {},
+  onStart: (payload, { ctx }) => {},
   run: async (payload, { ctx }) => {},
 });
 ```

package/docs/observability/dashboards.mdx

@@ -45,6 +45,68 @@ You can also filter the data by:
 4. For charts you write [TRQL queries](/observability/query) and choose a visualization type.
 5. You can resize and reposition widgets on your dashboards.
 
+## Managing dashboards with the SDK
+
+Custom dashboards can also be created and edited from code, so you can keep them in your repository and set them up from CI or a script. `query.dashboards` covers the same operations as the dashboard UI.
+
+```ts scripts/dashboards.ts
+import { query } from "@trigger.dev/sdk";
+
+const dashboard = await query.dashboards.create({
+  title: "Email tasks",
+  widgets: [
+    { title: "Overview", display: { type: "title" } },
+    {
+      title: "Total runs",
+      query: "SELECT count() AS total FROM runs WHERE task_identifier = 'send-email'",
+      display: { type: "bignumber", column: "total", aggregation: "sum" },
+    },
+    {
+      title: "Runs per day",
+      query:
+        "SELECT timeBucket(), count() AS runs FROM runs WHERE task_identifier = 'send-email' GROUP BY timeBucket ORDER BY timeBucket",
+      display: {
+        type: "chart",
+        chartType: "bar",
+        xAxisColumn: "timebucket",
+        yAxisColumns: ["runs"],
+        groupByColumn: null,
+        stacked: false,
+        sortByColumn: null,
+        sortDirection: "asc",
+        aggregation: "sum",
+      },
+    },
+  ],
+});
+
+console.log(dashboard.id); // dashboard_...
+```
+
+Widgets without a `position` are stacked full width in the order you list them. Pass `position: { x, y, w, h }` on a 12-column grid to place a widget yourself.
+
+To keep a dashboard in sync with code, replace all of its widgets in one call. Widgets you keep, matched by `id`, stay where they are unless you pass a new `position`:
+
+```ts scripts/dashboards.ts
+const current = await query.dashboards.retrieve(dashboard.id);
+
+await query.dashboards.replace(dashboard.id, {
+  widgets: [
+    {
+      id: "failures",
+      title: "Failed runs",
+      query: "SELECT count() AS failed FROM runs WHERE status = 'Failed'",
+      display: { type: "bignumber", column: "failed", aggregation: "sum" },
+    },
+  ],
+  revision: current.revision,
+});
+```
+
+`revision` is optional. When you pass the revision you last read, the write fails with a 409 if someone changed the dashboard in the meantime, instead of overwriting their change.
+
+Every widget query is checked against the queryable tables when you save it, so a typo in a table or column name fails the request with the list of valid columns. `query.dashboards.widgets.add`, `widgets.update` and `widgets.del` change one widget at a time. Creating a dashboard or widget past your plan's limits returns a 403. See the [Query API reference](/management/query/create-dashboard) for every endpoint.
+
 ## Performance considerations
 
 ### Optimize queries for metrics
@@ -98,5 +160,7 @@ There is a separate concurrency limits for metric widgets.
 | Limit                     | Details        |
 | :------------------------ | :------------- |
 | Concurrent widget queries | 30 per project |
+| Custom dashboards         | Free 0, Hobby 1, Pro 5 per organization |
+| Widgets per dashboard     | Free 0, Hobby 10, Pro 20 |
 
 See [Limits](/limits) for details.

package/docs/observability/query.mdx

@@ -8,6 +8,7 @@ description: "Query allows you to write custom queries against your data using T
 - `runs`: contains all task run data including status, timing, costs, and task output. Run metadata (key-value set in your task) is not available on the Query page.
 - `metrics`: contains metrics data for your runs including CPU, memory, and your custom metrics
 - `llm_metrics`: contains LLM/AI metrics including token usage, costs, latency, and model performance data from GenAI spans
+- `llm_models`: anonymized cross-tenant model performance aggregates (calls, cost, latency, throughput per model per minute); it has no tenant-specific data
 
 ### `metrics` table columns
 
@@ -24,6 +25,9 @@ description: "Query allows you to write custom queries against your data using T
 | `machine_name` | string | Machine preset (e.g., `small-1x`) |
 | `worker_version` | string | Worker version |
 | `environment_type` | string | `PRODUCTION`, `STAGING`, `DEVELOPMENT`, `PREVIEW` |
+| `worker_id` | string | Worker ID that produced the metric |
+| `environment` | string | Environment slug |
+| `project` | string | Project ref, starting with `proj_` |
 | `attributes` | json | Raw JSON attributes for custom data |
 
 See [Logging, tracing & metrics](/logging#automatic-system-and-runtime-metrics) for the full list of automatically collected metrics and how to create custom metrics. You can visualize this data on [Dashboards](/observability/dashboards).
@@ -68,7 +72,7 @@ ORDER BY timeBucket
 LIMIT 1000
 ```
 
-Available format types: `bytes`, `percent`, `duration`, `durationSeconds`, `quantity`, `costInDollars`.
+Available format types: `bytes`, `percent`, `duration`, `durationSeconds`, `quantity`, `costInDollars`, `decimalBytes`, `cost`.
 
 ## Using the Query dashboard
 
@@ -602,7 +606,7 @@ LIMIT 100
 
 We have several limits to prevent abuse and ensure performance:
 
-- **Concurrency limit**: We limit the number of concurrent queries per organization.
+- **Concurrency limit**: We limit the number of concurrent queries per project.
 - **Row limit**: We limit the number of rows returned to 10k.
 - **Time restrictions**: We limit the time period you can query.
 - **Time/Memory limit**: We limit the memory a query can use and the time it can run for. As well as other limits like AST complexity.

package/docs/private-networking/aws-console-setup.mdx

@@ -250,7 +250,7 @@ By default, no one can connect to your endpoint service. You need to explicitly
 
     - **Friendly name**: a short, human-readable label for this connection.
     - **VPC Endpoint Service name**: paste the `com.amazonaws.vpce.<region>.vpce-svc-...` value from Step 4.
-    - **Target region**: the AWS region your endpoint service lives in.
+    - **Target region**: the Trigger.dev region where the VPC Endpoint is created (pick one from the list, such as `us-east-1` or `eu-central-1`), normally the region your tasks run in. If it differs from the region your endpoint service lives in, enable cross-region access in Step 3.
 
   </Step>
   <Step title="Submit">

package/docs/private-networking/overview.mdx

@@ -119,7 +119,7 @@ All three conditions must be true. No organization can route traffic to another
 
 ## Limits
 
-- **Two connections per organization.** This is a soft limit — get in touch if you need more.
+- **Four connections per organization.** This is a soft limit — get in touch if you need more.
 - **All ports accepted.** Our security group allows all TCP ports from peered CIDRs. You control which ports are reachable through your NLB and target groups.
 - **Same-region or cross-region.** Connections work within the same region as your tasks or across regions (cross-region adds AWS-level cost and ~10-30ms latency).
 

package/docs/quick-start.mdx

@@ -8,48 +8,11 @@ import CliInitStep from "/snippets/step-cli-init.mdx";
 import CliDevStep from "/snippets/step-cli-dev.mdx";
 import CliRunTestStep from "/snippets/step-run-test.mdx";
 import CliViewRunStep from "/snippets/step-view-run.mdx";
+import AgentSetupPrompt from "/snippets/agent-setup-prompt.mdx";
 
-## Set up with AI
+## Copy the setup prompt
 
-Using an AI coding assistant? Copy this prompt and paste it into Claude Code, Cursor, Copilot, Windsurf, or any AI tool. It'll handle the setup for you.
-
-<Accordion title="Copy the setup prompt">
-
-```text
-Help me add Trigger.dev to this project.
-
-## What to do
-
-1. I need a Trigger.dev account. If I don't have one, point me to https://cloud.trigger.dev to sign up. Wait for me to confirm.
-2. Run `npx trigger.dev@latest init` in the project root.
-   - When it asks about the MCP server, recommend I install it (best DX: gives you direct access to Trigger.dev docs, deploys, and run monitoring).
-   - Install the "Hello World" example task when prompted.
-3. Run `npx trigger.dev@latest dev` to start the dev server.
-4. Once the dev server is running, test the example task from the Trigger.dev dashboard.
-5. Create a named API key in my Development environment with **Trigger only** access. Set it as TRIGGER_SECRET_KEY in my .env file (or .env.local for Next.js).
-6. Ask me what framework I'm using and show me how to trigger the task from my backend code.
-
-If I've already run init and want the MCP server, run: npx trigger.dev@latest install-mcp
-
-## Critical rules
-
-- ALWAYS import from `@trigger.dev/sdk`. NEVER import from `@trigger.dev/sdk/v3`.
-- NEVER use `client.defineJob()` — that's the deprecated v2 API.
-- Use type-only imports when triggering from backend code to avoid bundling task code:
-
-  import type { myTask } from "./trigger/example";
-  import { tasks } from "@trigger.dev/sdk";
-
-  const handle = await tasks.trigger<typeof myTask>("hello-world", { message: "Hello from my app!" });
-
-## When done, point me to
-
-- Writing tasks: https://trigger.dev/docs/tasks/overview
-- Real-time updates: https://trigger.dev/docs/realtime/overview
-- AI tooling: https://trigger.dev/docs/building-with-ai
-```
-
-</Accordion>
+<AgentSetupPrompt />
 
 ## Manual setup
 

package/docs/realtime/auth.mdx

@@ -157,7 +157,7 @@ const { parts } = useRealtimeStream<{ url: string }>(runId, "frames", {
 
 When you [trigger tasks](/triggering) from your backend, the `handle` received includes a `publicAccessToken` field. This token can be used to authenticate real-time requests in your frontend application.
 
-By default, auto-generated tokens expire after 15 minutes and have a read scope for the specific run(s) that were triggered. You can customize the expiration by passing a `publicTokenOptions` object to the trigger function.
+Auto-generated tokens expire after 1 hour and have a read scope for the specific run(s) that were triggered. For a different expiration or scopes, create a token yourself with [`auth.createPublicToken`](#creating-public-access-tokens).
 
 See our [triggering documentation](/triggering) for detailed examples of how to trigger tasks and get auto-generated tokens.