2 min lesson
Dashboards and query interfaces engineers actually use
Work through the cases in "Dashboards and query interfaces engineers actually use", pairing each signal with the move that fits.
Step 1 of 2
Dashboards and query interfaces engineers actually use
"Is my deploy regressing latency?" as a one-click view scoped to a commit.
"Success rate by model this week" without writing SQL.
Pre-built so the 80% of asks never reach you.
Every headline metric drills into model/region/client segments.
An engineer can localize a regression themselves.
Links straight to the deploy dimension for triage.
For the one-off end of the spectrum - a finding you want to see right now, not maintain - Canvas is the fast path. Cursor writes React to render a dashboard directly inside the IDE, so an anonymized CSV usage export becomes a live, clickable dashboard you iterate on by talking to it ("match the Cursor dashboard", "add a tooltip"). It takes an image, a CSV or the codebase as input. The decision rule keeps it from becoming shadow tooling: Canvas is for one-off visualization and sharing. If you want an always-on dashboard, have Cursor build a real website - a small Next.js app - and deploy it, so it joins the self-serve stack instead of living in someone's editor.
Canvas renders a dashboard in seconds, which is exactly why it tempts people into making it load-bearing. A dashboard the whole team relies on belongs in a deployed app behind the semantic layer, not in a Canvas view one person can edit. Use Canvas to explore and share a finding; promote anything durable to real tooling.