Your Practical Toolkit for Looker's "Day Two" Problems
So, you've been using Looker for a while. The initial work of building dashboards is done, and now you're living with the reality of managing a large, collaborative project. You've likely noticed that a sprawling LookML project can become a liability that slows down development and makes users lose trust.
Here is a no-nonsense guide to the essential third-party and open-source tools that solve the most common "Day Two" operational challenges.
LAMS (Look At Me Sideways)
Why We Recommend It: Your team writes LookML, but it's unlikely it all looks the same. LAMS is for making sure your code is consistent and readable, not just functional. Every codebase needs standards, LAMS helps you enforce them.
Who It's For: Looker Development Teams.
The tl;dr: You know your code will run because the Looker IDE has a validator that checks for syntactical correctness. But it won't enforce a consistent coding style or best practices. That's the gap LAMS was built to fill. It's a linter that checks your code against a set of style rules. You can use its built-in rules, write your own custom ones, and integrate it into your CI/CD pipeline via a GitHub Action. This automates code quality checks on every pull request, ensuring a clean and maintainable master branch.
Henry
Why We Recommend It: After a half-year or a year of use, you'll start to notice some dashboards, Looks, and Explores aren't being used anymore. As they say: it's much easier to add than it is to subtract. Henry helps you unbake the cake.
Who It's For: Looker Administrators and Developers.
The tl;dr: Over time, your Looker instance will accumulate "LookML bloat". Unused fields and joins from old projects that make the environment harder to navigate and can degrade performance. Henry is a command-line tool designed to fix this. It connects to your Looker instance, analyzes usage history over a time period you specify, and identifies what's not being used. It then provides a clear "to-do list" of unused content, giving you a high-confidence way to start cleaning up your project.
Data Warehouse + Looker Integration Tools (dbt2looker, Concordia, & Droughty)
Why We Recommend It: You use tools like Dataform, SQLmesh or dbt for data transformation and Looker for BI. This means you probably spend a lot of time manually keeping Looker view files in sync with your dbt models, an error-prone and tedious process. You should automate this.
Who It's For: Data teams using both SQL Orchestration frameworks and Looker.
The tl;dr: A discrepancy between a data model and its corresponding Looker view can silently break reports. These tools automate the generation of LookML from your warehouse to prevent this.
Droughty - made by the folks at Rittman Analytics. This reads your warehouse, and generates your looker models based on opinionated naming conventions. It also generates description and documentation. It’s pretty sophisticated. These folks know what they’re doing with dbt+looker.
Dbt2looker - made by the folks at lightdash. Lightdash is a Looker competitor, and it’s not been maintained for a while. The last commit was 3 years ago, but it’s pretty lightweight and generates your lookml files based on a dbt schema
Concordia - made by us! We work with dataform all the time so we built this CLI tool to scan your dataform repo, find your ‘mart’ or ‘analytics’ level datasets, and then generate base lookml views and an explore.
Spectacles - now Looker's Native Continuous Integration (CI)
Why We Recommend It: You push a LookML change. It passes the validator. But somewhere, a critical dashboard breaks or, worse, shows incorrect data. This provides a built-in safety net to catch those errors automatically.
Who It's For: Looker Development Teams.
The tl;dr: Ensuring changes don't break things is critical for maintaining trust in your BI platform. This functionality was so essential that Google acquired Spectacles, the leading third-party testing tool, and is integrating its core features directly into Looker as a native CI function. When you open a pull request, the CI job automatically runs to validate the proposed changes. It checks for broken content, runs data tests, and validates that the compiled SQL is correct, catching errors before they ever reach production.
Gazer (gzr)
Why We Recommend It: You built the perfect dashboard on the development instance. Now what? Manually recreating it in production is not a viable strategy. Gazer is how you migrate content properly.
Who It's For: Administrators and developers managing multiple Looker instances (e.g., dev/prod).
The tl;dr: Gazer is an open-source, command-line tool that lets you treat Looker content like code artifacts that can be scripted and version-controlled. Its cornerstone feature is the ability to export an entire Space of Looks and Dashboards into a directory of JSON files. You can check these files into Git for versioning and then use the import command to deploy them to another Looker instance, enabling a true CI/CD workflow for your BI content.
It basically ‘plugs the gap’ of the Looks and Dashboards being ‘unchecked’ into version control.
Visualizing Your Model (LookML Diagram & lookml-tools Grapher)
Why We Recommend It: Onboarding a new team member to a complex LookML project is hard when there's no map. These tools create that map.
Who It's For: New developers, or any developer trying to understand or debug a complex model.
The tl;dr: A visual representation of your model architecture can dramatically simplify understanding how it all fits together. You have two main options:
LookML Diagram: This is an official application from Google, available in the Looker Marketplace. It provides an Entity-Relationship Diagram (ERD)-style visualization of how views are joined together directly inside the Looker UI.
lookml-tools Grapher: This is an open-source Python tool that generates a PNG network diagram illustrating the model-explore-view relationships in your project. A key feature is its ability to identify "orphans"—views that are defined but not referenced by any Explores, making them prime candidates for cleanup. Henry would catch them, in any case.
Improving the Development Experience: vscode-looker
Why We Recommend It: Because while the native Looker IDE works, writing code in a real IDE like VS Code is just better. (Full disclosure: we maintain this one).
Who It's For: Looker Developers who prefer a local development workflow in VS Code.
The tl;dr: The web-based IDE in Looker gets the job done for basic edits, but for serious development, it lacks the features of a modern code editor. The vscode-looker extension brings LookML development into Visual Studio Code. It provides essential features you'd expect, like advanced syntax highlighting, code snippets to speed up your work, and the ability to quickly jump to definitions. It also includes a project explorer to easily navigate your models and can integrate with other tools like the LAMS linter, creating a much more powerful and efficient local development workflow.
