Every Looker environment tells the same story if you know where to read it. After years of auditing enterprise instances, the findings cluster with remarkable consistency: Explores nobody has opened in a quarter, PDTs rebuilding history nightly to add a day, permission models that grew by exception, and a BigQuery bill that nobody can attribute to anything specific. Our audits find 27% recoverable spend on average — not because environments are badly built, but because entropy is undefeated and nobody's job is to fight it.
This article is the checklist we actually use, in full: 25 checks across six areas, with what "good" looks like and why each one matters. We're publishing it for the same reason we publish our cost tactics and our performance diagnostic: most of this is knowable in an afternoon with Admin access, and an informed team is a better client — or a team that doesn't need us at all, which is also fine.
Two ways to use it: read through and score yourself mentally, or use the interactive version of this checklist on our site, which tracks your score as you go. For each check below, answer honestly. Score one point per "yes." Interpretation guide at the end.
What you need: Looker Admin (or see_system_activity) access, read access to your BigQuery console, and about two hours. Everything here is read-only.
Block 1 — LookML and semantic layer health
The model is the foundation; when it's messy, everything above it is slow, expensive, or wrong.
1. Is the LookML project structured by convention — and could a new developer find things?
Consistent folder organization, view/Explore naming that follows a pattern, model files that don't sprawl. The test: could a competent LookML developer who has never seen your project locate the definition of your core revenue measure in five minutes? If the answer is "only Alex knows where that lives," you have a bus-factor problem wearing a code-style costume.
2. Are views and Explores free of duplication?
Two views on the same table, three Explores answering the same question, copy-pasted dimensions with slightly different logic. Duplication is how metric drift starts: two Explores, two answers, zero trust.
3. Are joins documented, deliberate, and fanout-safe?
Every join in an Explore should exist because queries need it, with relationship types (one_to_many etc.) declared correctly. Wrong relationship declarations produce silently inflated numbers — the worst class of BI bug, because nobody notices until the board deck disagrees with the ERP.
4. Does shared logic live in shared places?
Repeated CASE statements, repeated date math, repeated business rules across views — logic that should be defined once (in a base view, an extended view, or upstream in dbt) and reused. Repetition means every business-rule change is a scavenger hunt.
5. Are LookML best practices in use — group labels, descriptions, templated filters, includes hygiene?
Fields with description, Explores with group_label, deprecated fields actually hidden, include statements scoped instead of *. This is what makes self-service real: users can only serve themselves from a menu they can read.
Block 2 — Dashboard and Explore performance
Slow dashboards kill adoption quietly. These checks find the slowness before your users report it as "I stopped using Looker." (The full diagnostic lives in why your Looker dashboards are slow; the fixes are the core of our performance optimization service.)
6. Do your key dashboards load in under 5 seconds?
Not the average dashboard — the ten most-viewed ones, from System Activity. If executives wait 30 seconds, they stop looking, and the data team's influence decays with the load time.
7. Is any dashboard firing more than ~15 queries on load?
Every tile is a query; 25-tile dashboards queue against concurrency limits, so the last tile waits for all the others. Oversized dashboards are usually three dashboards wearing a trench coat.
8. Do exploratory dashboards require filters before running?
Filter-first dashboards prevent the default no-filter view — often the most expensive query in the building — from running for every visitor who came to check one region.
9. Are tile queries optimized — no detail-grain scans for summary questions?
Check the generated SQL on your slowest tiles. A monthly-trend tile aggregating raw event rows on every load is the signature of missing aggregate awareness (aggregate_table rollups fix it transparently).
10. Are caching and datagroups aligned with how often data actually changes?
If ELT lands at 6 a.m. and your datagroup expires hourly, you re-query unchanged data 23 times a day — paying in latency and warehouse spend. Look for sql_trigger datagroups tied to load timestamps, and for near-zero cache-hit rates in System Activity as the tell.
11. Do queries select only what they use — and do PDTs avoid SELECT *?
Derived tables built with SELECT * inherit every column forever, including the heavy ones added later. BigQuery bills the columns you touch.
Block 3 — BigQuery cost efficiency
The warehouse is where slow becomes expensive. (The full playbook is in How to cut BigQuery costs; these are the audit checks, and the deeper service is BigQuery cost optimization.)
12. Are large tables partitioned — and do Looker filters actually reach the partition column?
The check has two halves. Tables over ~1 GB queried by time should be date-partitioned, and the Explore's filters must map directly onto the partition column (an always_filter helps enforce it). Partitioning that queries can't prune is decoration.
13. Is clustering applied on frequently filtered columns?
Clustering is free and routinely cuts scanned bytes another 30–90% inside partitions. Any big, frequently filtered table without it is leaving money on the table — literally per query.
14. Do you know your ten most expensive queries — and does anything scan more than it should?
INFORMATION_SCHEMA.JOBS ranks them in one query. If nobody in the room can name the top offender, cost is unmanaged by definition.
15. Are there dashboards or schedules that trigger disproportionately large scans?
Cross-reference System Activity with BigQuery job history: the one dashboard whose refresh scans terabytes, the hourly schedule feeding a weekly meeting. Also check for cost guardrails — max_bytes_billed on the Looker connection turns a catastrophic query into an error message.
16. Are tables right-sized — no unnecessarily wide tables, no expired scratch data still billing?
Wide tables punish every SELECT that touches them; staging datasets without table expiration accumulate forever. Bonus check: has anyone compared logical vs physical storage billing per dataset? For compressible data, physical billing is often meaningfully cheaper.
17. Any cost anomalies in the last 30 days — and would you have noticed?
Look at daily spend for the last month. Any unexplained spike is a finding twice over: once for the spike, once for the fact that no alert caught it.
Block 4 — Pipelines and orchestration
Looker is downstream of everything; unreliable pipelines make even a perfect model wrong.
18. Do pipelines and PDT builds succeed reliably — and does anyone know when they don't?
Check failure rates for the last 30 days (Airflow/Composer, dbt, Airbyte, and Looker's PDT Event Log). Then the sharper question: when something fails at 3 a.m., does a human find out from an alert — or from a stakeholder at 9?
19. Are transformations free of redundancy — and is materialization incremental?
Two pipelines computing near-identical tables for two teams; PDTs rebuilding three years of history nightly to append one day. Deduplication and incremental builds are usually the two biggest pipeline savings in an audit.
20. Are schedules sequenced deliberately — and documented?
Loads finish before transforms start; transforms finish before PDT builds; builds finish before humans arrive. Collisions cause the "slow every Monday at 9" pattern. And each pipeline should have enough documentation that its failure doesn't require archaeology.
Block 5 — Governance and security
Governance debt is invisible until the day it's an incident.
21. Do permissions follow least-privilege — with roles that mean something?
Viewer/Explorer/Developer boundaries used as designed, model sets scoping who sees what, no "everyone is Admin because it was easier during the rollout." Count your Admins; the number is a finding by itself in most audits.
22. Are user attributes and access filters implemented correctly for row-level security?
If regional managers should only see their region, that rule should live in access_filter + user attributes — declared once, applied to every query — not in per-dashboard filters that any Explorer can remove.
23. Is content organized in a folder hierarchy with intentional access — and are sensitive data protected?
A clear folder scheme (departmental, with curated shared spaces) instead of a thousand-item "Shared" flatland; PII fields restricted or masked; sensitive Explores scoped to the groups that need them.
Block 6 — Observability and monitoring
The meta-check: everything above regresses unless something watches it.
24. Is anyone monitoring performance, cost, and freshness — with alerts, not vibes?
Dashboards tracking p90 load times for key content, PDT build durations, daily BigQuery spend by project/user, pipeline error counts — with alerts to Slack/Teams when baselines break. The environments that stay healthy are the ones where degradation pages someone.
25. Do you review usage — and retire what's dead?
System Activity knows which dashboards, Looks, and Explores nobody has touched in 90 days. A quarterly cleanup ritual is the difference between a governed platform and an archaeological site. Unused content isn't just clutter: its schedules and PDTs cost real money monthly.
Scoring your environment
Count your honest "yes" answers:
- 21–25 — Healthy. You're in the top tier of environments we see. Your risk is regression, not repair: make sure block 6 is solid so it stays this way.
- 14–20 — Typical. This is where most established instances live. There's meaningful recoverable cost and speed here — usually concentrated in blocks 2 and 3. Prioritize the failed checks that appear in pairs (unpartitioned tables + slow dashboards; no monitoring + cost anomalies): paired findings share a root cause and fix together.
- 7–13 — Accumulating debt. The environment works, but expensively, and trust is probably eroding at the edges. A structured 6–8 week optimization pass typically moves environments in this band dramatically — this is the profile behind our 30–60% cost reduction and 40%+ dashboard speedup numbers, and the profile in our performance and cost optimization case study.
- 0–6 — Fragile. Every incident is an investigation, every number is negotiable, and the bill grows monthly. Before adding anything new to this platform, stabilize it — foundation work first.
Whatever you scored, the failed checks are now a prioritized to-do list — that's the real product of an audit, and you just ran a meaningful chunk of one for free. (Prefer to track it as you go? The interactive checklist scores you automatically.)
What the professional version adds
Fair question: if the checklist is public, what does the paid audit buy?
Depth per finding and a number on each one. The self-service checklist tells you that check 14 fails; the audit tells you which twelve queries, what each costs per month, what the fix is, in what order, and what the total recoverable spend adds up to — a prioritized plan with estimated impact per finding, delivered in one week for $1,500 fixed, with a 90-minute walkthrough. The free 15-minute version sits in between: read-only, we name your biggest offenders and the estimated recoverable number, and if your environment is genuinely healthy we tell you that and you've lost nothing. Ongoing work afterwards — if you want it — runs through our Looker consulting practice.
Either way, run the checklist first. The teams that show up already knowing their score get more out of every conversation — with us or anyone else.
Frequently asked questions about Looker audits
What is a Looker audit?
A Looker audit is a structured review of a Looker environment across six areas: LookML and semantic-layer health, dashboard and Explore performance, BigQuery cost efficiency, pipeline reliability, governance and security, and observability. The output is a prioritized list of findings with estimated impact — which queries, PDTs, Explores, and configurations are costing time and money, and in what order to fix them.
How long does a Looker audit take?
The self-service version of this checklist takes about two hours with Admin access. Our free read-only check takes 15 minutes and names your biggest offenders. The full scoped audit is delivered in one week: complete review of LookML, performance, cost, and governance, with a prioritized action plan and a 90-minute walkthrough.
What access is needed to audit a Looker instance?
Read-only access is enough for a first pass. The key sources are Looker's System Activity (query history, PDT event log, content usage), the LookML project itself, and BigQuery's INFORMATION_SCHEMA for job costs and table structure. A serious audit never requires write access to production — everything is observation.
What are the most common problems found in Looker audits?
The findings cluster consistently: unpartitioned or unclustered tables forcing large scans, PDTs rebuilding full history instead of incrementally, missing aggregate awareness (summary dashboards querying detail-grain data), cache policies misaligned with data load schedules, duplicated Explores causing metric drift, over-permissioned users, and no cost or performance monitoring. Our audits find an average of 27% recoverable BigQuery spend.
How much does a professional Looker audit cost?
Our free check costs nothing: 15 minutes, read-only, and we name the estimated recoverable spend — if we find nothing worth fixing, we tell you. The full scoped audit is $1,500 fixed, delivered in one week. Ongoing optimization after the audit is either a fixed-scope project or fractional support from $2,000/month.
How often should we audit our Looker environment?
A full audit once a year, plus a quarterly self-service pass focused on blocks 2, 3, and 6 (performance, cost, monitoring) — those are the areas that regress fastest as data grows and content accumulates. If you have monitoring and alerts in place (check 24), the quarterly pass takes an hour because the dashboards already know the answers.
Can I run this Looker audit checklist myself?
Yes — that's why we published it. Everything in the checklist is checkable with Admin or see_system_activity access plus read access to BigQuery, in about two hours. There's also an interactive version on our site that tracks your score. What a professional audit adds is depth per finding: the specific offenders, the monthly cost of each, and a sequenced fix plan.
What's the difference between the free audit and the $1,500 audit?
The free audit is 15 minutes, read-only: we identify your biggest offenders — unused Explores, disproportionately expensive queries, slow dashboards — and give you the estimated recoverable cost in your monthly bill. The $1,500 audit is the full week-long version: every area of this checklist reviewed in depth, each finding quantified, a prioritized action plan, and a 90-minute walkthrough with your team. The free version tells you whether the full one is worth it.
What happens after the audit findings are delivered?
Three paths, and the audit is priced to stand alone in all of them: your team implements the plan (everything is documented for that), we implement it as a fixed-scope project priced from the audit, or we work embedded with your team as fractional support from $2,000/month. There's no obligation to continue — the audit report is designed to be useful regardless of who executes it.
Know your score. Then decide.
Run the checklist yourself, or let us run the 15-minute read-only version and name your biggest offenders and the estimated recoverable spend. If your environment is healthy, we tell you that — and you've lost nothing.
