docs(queues): Cover new queue limits and TTL system

Author: ericallam

docs/limits.mdx

@@ -31,13 +31,21 @@ You can request a higher rate limit from us if you're on a paid plan.
 
 ## Queued tasks
 
-The number of queued tasks by environment.
+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.
 
-| Limit   | Details            |
-| :------ | :----------------- |
-| Dev     | At most 500        |
-| Staging | At most 10 million |
-| Prod    | At most 10 million |
+<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).
+</Note>
+
+| Pricing tier | Development (per queue) | Staging / Production (per queue) |
+| :----------- | :---------------------- | :-------------------------------- |
+| Free         | 500                     | 10,000                            |
+| Hobby        | 500                     | 250,000                           |
+| Pro          | 5,000                   | 1,000,000                         |
+
+## Maximum run TTL
+
+On Trigger.dev Cloud, all runs have an enforced maximum TTL of 14 days. Runs without an explicit TTL automatically receive the 14-day TTL; runs with a TTL longer than 14 days are clamped to 14 days. This prevents queued runs from accumulating indefinitely. 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).
 
 ## Schedules
 

docs/runs.mdx

@@ -161,7 +161,7 @@ await yourTask.trigger({ foo: "bar" }, { ttl: "10m" });
 
 If the run hasn't started within the specified TTL, it will automatically expire, returning the status `Expired`. This is useful for time-sensitive tasks where immediate execution is important. For example, when you queue many runs simultaneously and exceed your concurrency limits, some runs might be delayed - using TTL ensures they only execute if they can start within your specified timeframe.
 
-Note that dev runs automatically have a 10-minute TTL. In Staging and Production environments, no TTL is set by default.
+Dev runs automatically have a 10-minute TTL. On Trigger.dev Cloud, staging and production runs have a maximum TTL of 14 days applied automatically (runs without an explicit TTL get 14 days; longer TTLs are clamped). See [Limits — Maximum run TTL](/limits#maximum-run-ttl) for details.
 
 ![Run with TTL](/images/run-with-ttl.png)
 

docs/self-hosting/env/webapp.mdx

@@ -136,6 +136,9 @@ mode: "wide"
 | `RUN_ENGINE_RATE_LIMIT_REQUEST_LOGS_ENABLED`     | No       | 0                     | Run engine rate limit request logs.                                                                       |
 | `RUN_ENGINE_RATE_LIMIT_REJECTION_LOGS_ENABLED`   | No       | 1                     | Run engine rate limit rejection logs.                                                                     |
 | `RUN_ENGINE_RATE_LIMIT_LIMITER_LOGS_ENABLED`     | No       | 0                     | Run engine rate limit limiter logs.                                                                       |
+| `RUN_ENGINE_DEFAULT_MAX_TTL`                     | No       | —                     | Maximum TTL for all runs (e.g. "14d"). Runs without a TTL use this as default; runs with a larger TTL are clamped. |
+| `MAXIMUM_DEV_QUEUE_SIZE`                         | No       | —                     | Maximum queued runs per queue in development environments.                                                |
+| `MAXIMUM_DEPLOYED_QUEUE_SIZE`                    | No       | —                     | Maximum queued runs per queue in deployed (staging/prod) environments.                                   |
 | **Misc**                                         |          |                       |                                                                                                           |
 | `TRIGGER_TELEMETRY_DISABLED`                     | No       | —                     | Disable telemetry.                                                                                        |
 | `NODE_MAX_OLD_SPACE_SIZE`                        | No       | 8192                  | Maximum memory allocation for Node.js heap in MiB (e.g. "4096" for 4GB).                                  |

docs/triggering.mdx

@@ -780,6 +780,10 @@ The timeline would look like this:
 
 For this reason, the `ttl` option only accepts durations and not absolute timestamps.
 
+<Note>
+  On [Trigger.dev Cloud](https://trigger.dev), there is a maximum TTL of 14 days. If you don't specify a TTL in staging or production, runs automatically get a 14-day TTL. If you specify a TTL longer than 14 days, it is clamped to 14 days. See [Limits — Maximum run TTL](/limits#maximum-run-ttl) for details.
+</Note>
+
 ### `idempotencyKey`
 
 You can provide an `idempotencyKey` to ensure that a task is only triggered once with the same key. This is useful if you are triggering a task within another task that might be retried: