Use the observability dashboards

Important

This feature is in Beta. Workspace admins can control access to this feature from the Previews page. See Manage Azure Databricks previews.

When you configure observability for a project, Lakebase creates ready-made Lakeview dashboards over your telemetry tables, so you get rich, interactive charts of your Postgres activity without building any yourself. They read the same Delta tables in Unity Catalog that Insights and Genie use.

The project's Monitoring page has two tabs. The Metrics tab is always there, with live graphs of a single compute (CPU, memory, connections, cache hit rate) for a zero-setup answer to "is my database healthy right now?" The Advanced Postgres Telemetry tab appears once you configure observability, and holds a card linking to each of these dashboards. Because they run over the telemetry captured to Delta tables, they persist across restarts and answer the questions Metrics can't: which query is slow, whether a plan changed, and what differs between two time intervals.

Prerequisites

• A Lakebase Autoscaling project with observability configured and a running compute.
• The dashboards are created the first time the configuration writes telemetry, so give it a few minutes after you first set observability up. Like the tables, they don't appear until telemetry has flowed at least once.

Open a dashboard

Open a project's dashboards from the Advanced Postgres Telemetry tab:

1. Open your project and go to Monitoring.
2. Select the Advanced Postgres Telemetry tab. It lists a card for each dashboard the project's observability configuration creates.
3. Click a card to open that dashboard in Databricks SQL, in a new tab. The dashboard opens filtered to the branch's primary (read/write) endpoint.

If the tab shows an empty state instead of cards, one of two things is missing:

• No configuration assigned — the project isn't monitored yet. Assign or create an observability configuration in the project's settings first. See Capture telemetry to the Lakehouse.
• No dashboards yet — a configuration is assigned but hasn't created its dashboards yet. They appear once the configuration provisions them, shortly after telemetry first flows.

Note

You can also open the dashboards directly. In the workspace, go to Dashboards and search for Lakebase Overview or Lakebase Time Interval Comparison. Because the dashboards are ordinary Lakeview dashboards in your workspace (see The dashboards are yours), they're searchable there like any other.

The default dashboards

Two dashboards are created for every observability configuration. Each dashboard has filters that scope its views, so you can narrow to the time window and compute you care about. The exact filters and where they live differ between the two dashboards, as described below.

Lakebase Overview

A broad view of a project's health and performance over a time range, for one or more endpoints. It has three pages.

The Overview page covers compute, connections, queries, and waits at a glance:

Graph	What it shows	Reads from
CPU & RAM Over Time	Compute CPU and memory usage across the selected window.	compute_gauges
CPU Usage Over Time (Cores in Use)	Cores in use over time. Sustained periods near your allocated CPU indicate the compute is CPU-bound.	compute_counters
Disk I/O Over Time (MB/s)	Disk read/write throughput over time.	compute_counters
Network I/O Over Time (MB/s)	Network throughput over time.	compute_counters
Connections per Endpoint	Connection count over time, broken out by endpoint.	active_session_history
Active Sessions Over Time	Concurrent active sessions over time.	active_session_history
Query Execution Volume Over Time	How many queries ran over time.	pg_stat_statements_counters
Avg Query Execution Time (ms)	Average query latency over time.	pg_stat_statements_counters
Top 20 Queries by Call Count	The most frequently executed queries in the window.	pg_stat_statements_counters
Top 10 Queries: Total Exec Time Over Time	The queries consuming the most total execution time, tracked over the window.	pg_stat_statements_counters
Top 10 Queries: % Change Avg Exec Time (vs Mean)	Queries whose average latency deviates most from their own mean, to surface regressions.	pg_stat_statements_counters
Wait Time by Class Over Time	Time spent waiting, broken out by wait class (locks, I/O, and others), over time. Which class dominates points to where queries are blocked.	wait_event_counters
Top 25 Slowest Queries (Plan History)	The slowest individual executions captured in plan history.	plan_history
LFC Memory Overview by Endpoint	Local file cache memory use by endpoint, an indicator of working-set size.	compute_gauges

The Query Analysis page drills into a single query (selected with the page's Query ID filter):

Graph	What it shows	Reads from
Query Calls & Avg Exec Time Over Time	Call volume and average latency for the selected query over time.	pg_stat_statements_counters
Execution Time per Plan Hash	Execution time by plan hash, so you can see when a query's plan changed and how each plan performs. A sudden slowdown often appears here as a new, slower plan hash.	plan_history
Query Duration Stats	Duration statistics for the selected query's executions.	plan_history
Avg I/O Stats Over Time	Average I/O the selected query performed over time.	plan_history
Top 5 Longest Executions	The five slowest individual executions of the selected query.	plan_history

The Global Filters page holds the controls that scope every other page: Date Range, Endpoint, and Include Postgres Database.

Lakebase Time Interval Comparison

Compares an endpoint's activity across two time intervals you pick (a "before" and "after") to surface changes and regressions, for example after a deploy or a traffic spike. You set Period A and Period B with the date-range pickers and choose the endpoint, then read the two periods side by side:

Graph	What it shows	Reads from
Top Wait Events — Period A / Period B	The dominant wait events in each period, as side-by-side bars.	wait_event_counters
Wait Events Over Time — Period A / Period B	How wait events trend within each period.	wait_event_counters
Wait Events Comparison Table	Wait events for the two periods in one table, so shifts stand out.	wait_event_counters
Queries Comparison Table	Query statistics for the two periods side by side, to spot which queries got slower or busier.	pg_stat_statements_counters

For what every column in these tables means, see Telemetry table reference.

Share a dashboard

The dashboards are created as drafts that you own, so you can open and use them right away.

If you want to share a dashboard with other users, publish it. When you publish, you choose how its queries run for those viewers:

• Embedded credentials — queries run as the publisher, and you manage access at the dashboard level. This is the simpler option.
• Viewer credentials — queries run as each viewer, so you grant them permissions on the underlying telemetry tables. This is more work, but it lets others run their own custom queries against the same data.

Customize and extend a dashboard

The dashboards are yours to change. Because each is an ordinary Lakeview dashboard, you can edit it like any other: retitle or remove graphs, change visualizations, adjust the default filters, or add your own graphs and pages backed by the same telemetry tables (or joined with any other data in Unity Catalog). For how to edit Lakeview dashboards, see Dashboards.

If you'd rather keep the originals untouched, clone a dashboard first and customize the copy.

To build entirely new views, write your own queries against the telemetry tables with any Azure Databricks SQL tool. The data is standard Delta in your own Unity Catalog.

The dashboards are yours

The dashboards and the telemetry tables are user-owned. Lakebase creates them, but they belong to you, and removing the configuration never removes them:

• Deleting the observability configuration doesn't delete them. If you delete or reassign a configuration, its dashboards and telemetry tables stay in place. Any edits you made to a dashboard are preserved. Remove them yourself if you no longer want them.
• Changing where a configuration writes (its catalog, schema, or table prefix) leaves the existing dashboards alone and creates a fresh dashboard pointed at the new destination. The earlier dashboard remains as your standalone content.

Because they're standard Lakeview dashboards and Delta tables in your own Unity Catalog, they behave like any other content you own, rather than being locked inside a separate observability product. See Where your data lives.

Next steps

• Capture telemetry to the Lakehouse — set up the observability configuration that creates these dashboards.
• Telemetry table reference — every table and column the graphs read from.
• Find and resolve issues with Insights — let a background agent surface issues from the same telemetry.
• Diagnose and fix issues with Genie — investigate a problem conversationally.