Monitor Looker Explore Metrics

For companies running Looker on BigQuery, the Looker Explore is where business users actually interact with data. Every dashboard tile, Look, and ad hoc analysis runs through an Explore, and every one of those queries is billed by BigQuery. Yet Looker and BigQuery each show only half the picture: Looker knows which Explore a query came from, and BigQuery knows what it cost. It is hard to answer basic questions about any single Explore: what does it cost, is it reliable, and is it fast enough for the people using it?

Revefi tracks five KPIs at the Looker Explore level, lets you assign daily, weekly, or monthly goals to each one, and alerts you when an Explore misses its goal.

This page describes the problems teams solve by monitoring Looker Explore metrics.

Who this is for

• BI and analytics platform owners who manage Looker and need to know which Explores are expensive, slow, or failing.
• LookML developers and analytics engineers who build and maintain Explores and want to see the cost and performance impact of their changes.
• Data platform and data engineering leads who manage BigQuery spend and need to trace it back to the Looker content that drives it.
• FinOps and cloud cost analysts who allocate BigQuery spend to teams and track it against budget.
• Heads of data who report on the reliability and value of self-service analytics.

The KPIs

Revefi tracks the following KPIs for each Looker Explore:

You can assign a goal to any of these KPIs for any Explore, measured daily, weekly, or monthly. Revefi shows each Explore's KPIs against its goals in one view and alerts you when a goal is missed.

Keep Explore costs within budget

The problem

A single popular Explore can drive a large share of BigQuery spend. Because the cost shows up on the BigQuery bill rather than in Looker, it often goes unnoticed until month-end.

How Explore monitoring helps

Set a Cost goal for your most expensive Explores, for example a daily or monthly spend ceiling. Revefi alerts you when an Explore exceeds its goal, so you can investigate while the spike is still happening.

Pair it with a Data Processed goal to catch the root cause. A rise in data processed usually means a query stopped using partition filters, a join fanned out, or a new field pulled in a large table.

Outcome

Each Explore has a cost owner and a budget, and overruns are caught in days instead of at invoice review.

Catch broken Explores before users report them

The problem

A LookML change, a renamed column, or a permissions change can break an Explore. Users see errors on their dashboards, and the BI team usually hears about it from a support ticket.

How Explore monitoring helps

Set an Error Rate goal, for example no more than 2% of queries failing per day. When an Explore's error rate crosses the goal, Revefi alerts you so you can fix it before more users are affected.

Outcome

The BI team finds and fixes broken Explores first, and trust in self-service analytics goes up.

Keep dashboards fast

The problem

Slow Explores frustrate business users and drive them away from self-service analytics. Performance often degrades gradually as data grows, so no single day looks like a problem.

How Explore monitoring helps

Set a Fast Queries goal, for example at least 90% of queries completing quickly each week. A weekly or monthly goal surfaces gradual slowdowns that a daily view would miss.

Outcome

Performance regressions are caught early, and teams can prioritize LookML or table optimizations, such as aggregate awareness, persistent derived tables, or partitioning, where users feel them most.

Understand Explore adoption

The problem

Looker instances accumulate Explores that nobody uses, and it is hard to tell which ones are worth maintaining.

How Explore monitoring helps

Use Query Count to see how actively each Explore is used. Compare it with Cost to see whether an Explore's spend is justified by its usage:

• High cost, high query count: a heavily used Explore. Focus on making each query cheaper.
• High cost, low query count: a few expensive queries. Look for unfiltered queries or scheduled deliveries that scan large tables.
• Low query count over time: a candidate for deprecation or consolidation.

Outcome

Teams retire unused Explores, focus maintenance on the ones that matter, and can show the adoption of their Looker content.

Verify the impact of LookML changes

The problem

After a developer adds a partition filter, an aggregate table, or a persistent derived table, the team needs proof that the change improved cost and performance without breaking anything.

How Explore monitoring helps

Compare an Explore's KPIs before and after the change. A successful optimization shows lower Cost and Data Processed, a higher share of Fast Queries, a stable Error Rate, and a stable Query Count. A drop in query count after a change may mean users were affected.

Outcome

Teams can quantify the results of LookML work and report them.

Get started

1. Connect Revefi to Looker and to your BigQuery warehouse.
2. Open the Looker Explore metrics view to see the KPIs for each Explore.
3. Choose an Explore and assign goals to the KPIs you care about, with a daily, weekly, or monthly period.
4. Configure where alerts are sent, such as Slack or email.
5. Review missed goals as alerts arrive, and use the KPI trends to find the cause.