feat(webapp): dedicated ClickHouse service for queue metrics

Queue metrics can now run on their own ClickHouse service via
QUEUE_METRICS_CLICKHOUSE_URL: the ingestion consumer inserts through it
and every queue-metrics read goes through it, so metrics traffic never
competes with runs-list or trace reads. A table names the pool its reads
run on, so the dashboards, the Query page and the health report route by
table instead of each caller picking a client. Unset, the wiring is
unchanged: inserts on CLICKHOUSE_URL, reads on the query pool.

Also drops the queue-metrics seed simulator, splits the release notes so
percent-based queue limits and the reject-above-the-environment-limit
change get their own entries, and replaces a literal NUL byte in a cache
key with an escape, which had been making the health report's data layer
diff as a binary file.

Author: ericallam

.changeset/mcp-server-starts-without-wizard.md

@@ -0,0 +1,5 @@
+---
+"trigger.dev": patch
+---
+
+`trigger mcp` now always starts the MCP server, and the interactive install wizard has moved behind `trigger mcp --install`. Previously the wizard opened whenever stdout was a terminal, so any MCP host that spawns the command over a pseudo-terminal waited on a server that never started and eventually timed out.

.changeset/report-health.md

@@ -3,6 +3,10 @@
 "trigger.dev": patch
 ---
 
-Add the `get_report` MCP tool, a `trigger report` CLI command, and `GET /api/v1/reports/:key`, starting with the `health` report: a deterministic verdict on whether work is flowing, whether the runs that start are healthy, and whether telemetry is fresh — rendered as text with unicode sparklines (coloured in a terminal). Also adds a `report` MCP prompt, surfaced as a slash command in hosts that support prompts.
+Ask whether an environment is healthy and get an answer instead of a wall of charts. `trigger report health` returns a verdict on three questions: is work flowing, are the runs that start succeeding, and is the telemetry fresh enough to trust either answer. When something looks wrong it names the most likely cause and a next action.
 
-Also: `trigger mcp` now always starts the server — the install wizard is gated behind `trigger mcp --install`. A TTY previously launched the wizard, so MCP hosts spawning the server over a PTY timed out.
+```bash
+npx trigger.dev@latest report health --env prod --period 24h
+```
+
+The verdict is computed server side, so the CLI, the new `get_report` MCP tool, and `GET /api/v1/reports/health` all return the same text with the same sparklines. In MCP hosts that support prompts, `report` is also available as a slash command.

.server-changes/agent-detail-metrics-layout.md

@@ -3,4 +3,4 @@ area: webapp
 type: improvement
 ---
 
-The agent detail page now matches the shared metrics-page layout: the time filter and pagination sit in a filter row at the top, the activity charts form a tile row beneath it, and the tabs and table flow below in a single page scroll, with the agent config panel as a resizable sidebar on the right.
+The agent detail page now uses the same layout as the other metrics pages: filters stay pinned at the top, the activity charts sit in a row beneath them, and the tabs and table scroll with the page, with the agent config in a resizable panel on the right.

.server-changes/paginate-concurrency-keys-table.md

@@ -3,4 +3,4 @@ area: webapp
 type: improvement
 ---
 
-The concurrency keys table on a queue's page is now paginated, so queues with thousands of keys can page through all of them instead of only showing the top 50.
+A queue's concurrency keys are now paged and searchable, so a queue with thousands of keys shows all of them instead of only the busiest 50.

.server-changes/queue-concurrency-percent-limits.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: feature
+---
+
+A queue's concurrency limit can now be set as a percentage of your environment limit, from the dashboard or the API. Percentage limits track the environment limit, so raising or lowering it re-divides capacity without you editing every queue.

.server-changes/queue-metrics-dashboard.md

@@ -3,4 +3,4 @@ area: webapp
 type: feature
 ---
 
-New Queue metrics & health dashboard (per-org opt-in): per-queue depth, throughput, concurrency, throttling and scheduling-delay charts, a per-queue detail view, and live queue stats. Queue concurrency limits set above the environment limit are now rejected instead of being silently capped.
+See how every queue in an environment is doing: backlog, throughput, concurrency against its limit, when it was throttled, and how long runs waited before starting. Each queue also gets its own page, which breaks the same numbers down per concurrency key so you can tell whether one key is starving the rest.

.server-changes/reject-queue-limit-above-env-limit.md

@@ -0,0 +1,6 @@
+---
+area: webapp
+type: breaking
+---
+
+Setting a queue concurrency limit higher than your environment limit is now rejected with an error instead of being silently reduced to the environment limit, so a queue never looks like it has more capacity than it can get. Limits already saved are unchanged.

apps/webapp/app/env.server.ts

@@ -1952,6 +1952,22 @@ const EnvironmentSchema = z
       .enum(["log", "error", "warn", "info", "debug"])
       .default("info"),
     RUNS_LIST_CLICKHOUSE_COMPRESSION_REQUEST: z.string().default("1"),
+    /**
+     * Dedicated ClickHouse service for queue metrics: the ingestion consumer's inserts and every
+     * queue-metrics read (dashboards, queue pages, run inspector, health report) go through it, so
+     * metrics traffic never competes with runs-list or trace reads. Unset keeps the previous
+     * wiring: inserts on CLICKHOUSE_URL, reads on the query pool.
+     */
+    QUEUE_METRICS_CLICKHOUSE_URL: z.string().optional(),
+    /** Reader split so the consumer's inserts can never land on a read endpoint. Defaults to QUEUE_METRICS_CLICKHOUSE_URL. */
+    QUEUE_METRICS_CLICKHOUSE_READER_URL: z.string().optional(),
+    QUEUE_METRICS_CLICKHOUSE_KEEP_ALIVE_ENABLED: z.string().default("1"),
+    QUEUE_METRICS_CLICKHOUSE_KEEP_ALIVE_IDLE_SOCKET_TTL_MS: z.coerce.number().int().optional(),
+    QUEUE_METRICS_CLICKHOUSE_MAX_OPEN_CONNECTIONS: z.coerce.number().int().default(10),
+    QUEUE_METRICS_CLICKHOUSE_LOG_LEVEL: z
+      .enum(["log", "error", "warn", "info", "debug"])
+      .default("info"),
+    QUEUE_METRICS_CLICKHOUSE_COMPRESSION_REQUEST: z.string().default("1"),
     EVENTS_CLICKHOUSE_BATCH_SIZE: z.coerce.number().int().default(1000),
     EVENTS_CLICKHOUSE_FLUSH_INTERVAL_MS: z.coerce.number().int().default(1000),
     METRICS_CLICKHOUSE_BATCH_SIZE: z.coerce.number().int().default(10000),

apps/webapp/app/presenters/v3/QueueMetricsPresenter.server.ts

@@ -72,7 +72,7 @@ export class QueueMetricsPresenter {
     try {
       const clickhouse = await clickhouseFactory.getClickhouseForOrganization(
         environment.organizationId,
-        "query"
+        "queueMetrics"
       );
 
       // End bound snaps up to the bucket grid so repeated loads within a bucket produce

apps/webapp/app/presenters/v3/RunQueueMetricsPresenter.server.ts

@@ -145,7 +145,7 @@ async function delaySummary(input: {
   try {
     const clickhouse = await clickhouseFactory.getClickhouseForOrganization(
       input.organizationId,
-      "query"
+      "queueMetrics"
     );
 
     const endMs = Math.ceil(Date.now() / DELAY_GRID_MS) * DELAY_GRID_MS;