2 min lesson
Dashboards and query interfaces engineers actually use
Put yourself in this case. "A team has started relying on a Canvas dashboard built from a CSV export. What do you do?" Give the clearest next step.
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.
Every headline metric links straight to the deploy dimension, so an engineer can localize a regression without you.
For the one-off end of the spectrum, a finding you want to see right now rather than maintain, Canvas is the fast path. Ask Cursor for a dashboard or analysis and it opens as a canvas next to the chat, so an anonymized CSV usage export becomes a clickable dashboard you iterate on by talking to it ("match the Cursor dashboard", "add a tooltip"). Canvases are saved, so you can reopen one, rerun it with fresh data and, on a paid plan, share it with your team as a live-snapshot link. The decision rule keeps it from becoming shadow tooling: a shared canvas is a snapshot someone must rerun. If you want an always-on dashboard, have Cursor build a real website, a small Next.js app, and deploy it behind the semantic layer, 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. But a shared canvas is a snapshot, and someone has to republish it to refresh it. A dashboard the whole team relies on belongs in a deployed app behind the semantic layer. Use Canvas to explore and share a finding; promote anything durable to real tooling.
Learn more
Full explanation
Instrumentation and event-schema design upstream
Instrumentation and event-schema design upstream
You don't only analyze what's logged; you shape what gets logged. If the event schema doesn't carry model version, deploy id and a stable run id, no downstream cleverness recovers them. Designing instrumentation is the most impactful tooling work, because a missing field is a regression you can never attribute.
- Insist on a stable run_id and event ordering so sessionization is possible at all.
- Carry the triage dimensions (model version, deploy/commit, region, client version, surface) on the events themselves.
- Log the censoring signal (start, heartbeat, terminal) so aborted runs are distinguishable from fast ones.
- Treat schema as an interface: changes are versioned and announced, not silent.
Learn more
Full explanation
Data observability so trust doesn't erode silently
Data observability so trust doesn't erode silently
A self-serve metric is only as trusted as its freshness. If the pipeline stalls and a dashboard quietly shows yesterday's data as today's, engineers will make a bad call and then stop trusting every dashboard. Observability on the data itself is what keeps the tooling credible.
- Signal
- Freshness
- What it catches
- Pipeline stalled, stale numbers
- Failure if missing
- Decisions made on yesterday's data
- Signal
- Volume
- What it catches
- Row counts dropped or doubled
- Failure if missing
- A drop reads as a fake regression
- Signal
- Schema change
- What it catches
- A field renamed or nulled upstream
- Failure if missing
- Metric silently breaks, no error
- Signal
- Distribution drift
- What it catches
- A column's shape shifted unexpectedly
- Failure if missing
- Real regression hides in a broken input
| Signal | What it catches | Failure if missing |
|---|---|---|
| Freshness | Pipeline stalled, stale numbers | Decisions made on yesterday's data |
| Volume | Row counts dropped or doubled | A drop reads as a fake regression |
| Schema change | A field renamed or nulled upstream | Metric silently breaks, no error |
| Distribution drift | A column's shape shifted unexpectedly | Real regression hides in a broken input |
Trust is the product here; observability alerts are how you protect it.
Measure your tooling by adoption and offload, not by how many dashboards exist. The signals: engineers answering their own reliability questions, ad-hoc asks routed to you trending down and teams aligning on the same metric definition in their own docs. Dashboards nobody opens are not a win.
"I'd land a metric layer first so success rate means one thing across every team, then ship templated drill-down views for the top reliability questions and instrument the event schema with the dimensions triage needs. I'd judge it by ad-hoc asks dropping and engineers self-serving, with data-observability alerts so a stale pipeline never silently misleads a decision."
QTwo teams report different numbers for "agent success rate" and both are convinced theirs is correct. What's the structural fix and why is it tooling rather than a one-off reconciliation?