When a project feels slow, the useful question is narrow: is work not starting, or are the runs that start failing? Those are different problems with different fixes, and guessing between them wastes time. The health report separates the two and tells you which one you're actually looking at.
Three signals, one verdict
Every report reads three things independently. Flow is whether work is starting: pending counts, start latency, and concurrency-limit saturation. Execution is whether the runs that do start are succeeding: failure rate and durations measured against your normal. Liveness is whether the telemetry itself is fresh, so a green board never hides a dead pipe. Each axis gets its own headline verdict and a suggested next action.
The verdict is computed on the server from your metrics. There's no model in the diagnosis, so there's nothing to hallucinate, and the same inputs always produce the same answer.
Read the diagnosis, not just the number
When flow slows, the report walks a cause tree off your queue metrics (env-limit saturation, queue throttling, key starvation, a trigger spike, a dequeue stall). It names the likely cause and rules out the ones that don't fit, so you're not left correlating dashboards by hand.
/report health prod · last 1h · vs your 7d normal🟡 Flow slowing · 🟢 Execution healthy · 🟢 data freshFLOW 🟡 at your env concurrency limit (last 40 min) concurrency 100/100 ▁▅▆█████ pinned 40 of last 60 min pending 1,910 ↑ 16× ▁▁▂▃▅▅▇█ (normal ~120) start latency p95 42s ↑ 6× ▁▁▂▄▆▆▇█ (normal ~7s) worst queue email-sends — 82% of pending read: limit saturated → starts lag → backlog grows not workers, not platform — dequeue keeps pace at ~820/minEXECUTION 🟢 the runs that DO start are fine failures 1.3% (normal ~1.1%) · durations normalLIVENESS 🟢 fresh — last completion 4s ago→ Raise the env concurrency limit or do nothing — backlog drains in ~2.3 min once triggers ease
Run it wherever you are
The report renders from one server-side view model, so the verdict is identical in four places:
- CLI:
trigger report health, colorized in a terminal and plain markdown when piped. - MCP tool:
get_report, for your coding assistant, with unicode sparklines and 🟢/🟡/🔴 status markers. - MCP prompt:
/report health, a slash command in hosts that support prompts. - API:
GET /api/v1/reports/:key, withformatset tomarkdown,ansi, orjson.
Try it
Point the CLI at any environment and run:
npx trigger.dev@latest report health
You get the verdict for that environment right in your terminal, and get_report hands your coding assistant the same thing.