Telemetry

Count Telemetry gives workspace administrators deep visibility into how their Count environment is being used, from query performance and user activity to canvas engagement and AI agent behaviour.

Count telemetry is available on Scale plans and above.

Access & Permissions

  • Who has access by default: Workspace Owners are automatically granted access to telemetry data.
  • Granting access to others: Owners can share access to the telemetry connection in exactly the same way as any other database connection or project in Count, via the standard permission management UI.
  • API access: Your telemetry data is also accessible via the Count API.
  • A project named 'Admin telemetry' is also available and has a pre-populated canvas 'Query troubleshooting' which allows you to explore performance in your workspace.

What is available

Count Telemetry is exposed in two complementary ways:

1. The Count Telemetry Database Connection

A BigQuery database connection (called Count Telemetry) provides direct SQL access to the underlying raw telemetry tables.

The connection is refreshed once per day (between 4 and 5am UTC)

  • Table: `canvases`
    • Description: One row per canvas. Includes title, project, cache settings, alert config, and creation timestamp.
  • Table: `cells`
    • Description: One row per cell. Includes type (SQL, Python, visual, table, CSV), connection, and execution settings.
  • Table: `queries`
    • Description: One row per query execution. Includes duration, status, error, query engine, and user.
  • Table: `users`
    • Description: One row per workspace user. Includes name, email, role, and query activity aggregates.
  • Table: `canvas_loads`
    • Description: One row per canvas load event. Includes user, timestamp, load duration, and whether it was a report view.
  • Table: `cell_edits`
    • Description: One row per cell edit event. Includes user, timestamp, and edit type.
  • Table: `daily_edits`
    • Description: Aggregated daily editing activity per canvas and user.
  • Table: `downloads`
    • Description: One row per data download event from a cell. Includes user, canvas, cell, and timestamp.
  • Table: `app_errors`
    • Description: Application-level network errors. Includes error type, canvas, user, and timestamp.
  • Table: `agent_history`
    • Description: Full execution log of AI agent (Count AI) sessions. Includes sequence, type, role, content, and errors.
  • Table: `agent_queries`
    • Description: One row per query submitted by an AI agent. Links to the `queries` table via `query_key`.
  • Table: `agent_feedback`
    • Description: Feedback recorded against AI agent interactions.
  • Table: `connections`
    • Description: One row per database connection. Includes name, type, cache settings, and concurrency limits.
  • Table: `projects`
    • Description: One row per project in the workspace.
  • Table: `canvas_permissions`
    • Description: Canvas-level permission assignments (user, role, type).
  • Table: `canvas_permissions_resolved`
    • Description: Resolved effective permissions per user per canvas.
  • Table: `project_permissions`
    • Description: Project-level permission assignments.
  • Table: `keys`
    • Description: Central activity event log linking canvases, cells, users, connections, and events.
  • Table: `workspace`
    • Description: Workspace-level configuration: default cache settings, memory limits, DuckDB config.
  • Table: `groups`
    • Description: Workspace user groups.

Note: Improvements were made to the telemetry data on 15 June 2025, as a result some fields do not include data prior to this. This includes detailed query timing (queue, execution, extraction duration), query engine context, access mode, scheduled refresh flags, and monthly totals. Fields without a cutoff have full historical data.

2. The Admin Telemetry Catalog

The Admin Telemetry catalog provides a curated semantic layer on top of the raw telemetry tables. It is the recommended way to explore telemetry data — fields are pre-defined, labelled, and join logic is managed automatically.

Like the database, the catalog is refreshed once per day. Note that the Queries table in the catalog is restricted to a rolling 30-day query execution log. Use the database connection directly for full query history.

The catalog exposes 5 datasets, each combining multiple views:

Dataset: Assets

Centralized activity dataset mapping canvases, cells, permissions, and all system event actions.

The broadest dataset. Joins the keys event log to canvases, cells, users, connections, permissions, and all event types (edits, loads, downloads, errors, agent activity). Use this for cross-entity analysis or building a full audit trail.

Joined views: keys, canvases, cells, cell_edits, connections, app_errors, canvas_loads, canvas_deletions, daily_edits, downloads, project_permissions, canvas_permissions, canvas_permissions_resolved, projects, users, workspace, agent_history

Dataset: Queries

Rolling 30-day query execution log with performance details.

One row per query execution. Joins to cells, canvases, projects, connections, users, monthly totals, cell ownership, and agent attribution. Use this to understand query volume, performance, errors, and who is running what.

Key fields include: queries.duration_ms, queries.status, queries.error_type, queries.full_context (engine: database, duckdb, duckdb-server, cache, python), queries.query_role (editor, viewer, scheduled, alert), queries.started_at.

Joined views: queries, cells, canvases, projects, connections, users, queries_monthly_totals, cell_owner, agent_queries

Dataset: Agent Analytics

End-to-end view of AI agent (Count AI) activity.

Combines agent execution history with the queries those agents submitted. Use this to understand how often Count AI is being used, by whom, on which canvases, and how its queries perform.

Joined views: agent_history, agent_queries, queries, canvases, users

Dataset: Canvas Activity Analytics

Canvas load volumes and user discovery metrics.

Tracks every canvas load event. Use this to understand which canvases are most visited, by whom, how quickly they load, and whether they are being accessed in editor vs. report/viewer mode.

Joined views: canvas_loads, canvases, users

Dataset: Query Development Analytics

Cell edit history and development lifecycle tracking.

Tracks every cell query edit. Use this to understand which cells and canvases are most actively developed, and by whom.

Joined views: cell_edits, cells, canvases, users

  • View: `canvases`
    • Description: Canvas metadata including title, project, cell counts by type, cache settings, creation date
  • View: `cells`
    • Description: Cell metadata including type, connection, alert status, execution and limit settings
  • View: `queries`
    • Description: Query executions (30-day window): duration, status, error, engine, access mode, user
  • View: `queries_monthly_totals`
    • Description: Monthly aggregated query counts, durations, and error counts by engine
  • View: `users`
    • Description: User info: name, email, workspace role, total queries, last active timestamp
  • View: `connections`
    • Description: Database connections: name, type, cache/timeout/concurrency settings
  • View: `canvas_loads`
    • Description: Canvas load events: user, timestamp, duration, editor vs. report view
  • View: `cell_edits`
    • Description: Cell edit events: user, timestamp, edit type
  • View: `cell_owner`
    • Description: Derived cell ownership (last editor → most active → creator)
  • View: `daily_edits`
    • Description: Daily editing activity per canvas and user
  • View: `downloads`
    • Description: Data download events from cells: user, timestamp, editor vs. report view
  • View: `app_errors`
    • Description: Application network errors: type, user, canvas, timestamp
  • View: `agent_history`
    • Description: AI agent execution log: sequence, type, role, content, errors
  • View: `agent_queries`
    • Description: Queries submitted by AI agents, linkable to full query performance data
  • View: `workspace`
    • Description: Workspace configuration: cache defaults, memory limits, DuckDB settings
  • View: `projects`
    • Description: Project names and keys
  • View: `canvas_permissions`
    • Description: Canvas permission assignments
  • View: `canvas_permissions_resolved`
    • Description: Effective resolved permissions per user per canvas

Getting Started

Before users can analyse telemetry data, an Owner needs to make it available:

  1. Share the connection or catalog with a project. Go to the Count Telemetry connection or the Admin Telemetry catalog settings and add the project(s) you want to give access to. Users with access to those projects will then be able to query telemetry data from any canvas within them — just as they would any other connection.
  2. Use Count AI to get started quickly. The Count AI agent is a great starting point — open a canvas, describe what you want to understand (e.g. "show me the most active canvases in the last 30 days" or "which users have run the most queries?"), and Count AI will write and run the queries for you using the telemetry data available in the project.

Learn More

For a practical introduction to working with Count Telemetry to monitor and improve your AI agent, watch our webinar: Monitor agent quality and improve it over time:

Your agent is in the wild. Real users are asking real questions. Some are getting good answers. Some aren't. How do you know which is which — and how do you systematically make it better? This session covers the operational reality of running a self-serve agent at scale. Mitra and Jason walk through how to monitor agent quality using telemetry data, spot the patterns that signal something's wrong, and update context, schema, and data models based on real usage rather than guesswork. Most teams' agents quietly degrade over the first few months because no one's watching the right signals. By the end of this session, you'll know exactly what to watch and what to do about it.