Skip to content
Early access · Looker

Your metrics are already defined.
Now something watches them.

Lighthouse monitors the measures in your LookML.Your data team spent months getting the semantic layer right. Every other monitoring tool asks you to define those metrics a second time, in raw SQL. Lighthouse reads your Looker model directly: same joins, same filters, same numbers as your dashboards.

  • Read-only access
  • No LookML changes
  • Scoped to models you choose
  • 15 minute setup
A Lighthouse metric connecting to a Looker Explore

Your semantic layer is the best metric definition in the company.

Someone argued about what counts as an active user. Someone decided whether refunds come out of revenue. That work is finished, agreed, and living in your LookML.

Then monitoring asks you to do it all again in SQL, against raw tables, in a different tool. Now you maintain two definitions of every metric, and the moment someone updates the LookML, the monitoring copy is quietly wrong.

Your LookML

total_revenueactive_usersarpuconversion_rated7_retention

Months of work. Joins, filters, and business rules your whole company agrees on.

Dashboards

Uses your definitions ✓

Monitoring tools

Redefined in raw SQL ✗

Two definitions of the same metric. One of them drifts.

With Lighthouse

Monitoring reads the same LookML your dashboards do. One definition, everywhere.

Nothing to translate.

LookML already has the structure Lighthouse needs. Connect the instance and your model shows up ready to monitor.

Looker

Explore

Lighthouse

Dataset

Every Explore you can query becomes a dataset in Lighthouse

Looker

Measure

Lighthouse

Business metric

Total Revenue stays Total Revenue: same joins, same filters

Looker

Dimension

Lighthouse

Segment

Break any metric down by country, plan, channel, cohort

Looker

Dimension group

Lighthouse

Time grain

Daily, weekly, monthly: whichever your model already defines

Why not just use Looker alerts? For simple cases, do. Here’s where they run out.

What you can alert on

Lighthouse

Any measure in any Explore, directly. No tile required.

Looker native alerts

Dashboard tiles only. You have to build a tile first, and alerts can't be set on a Look page at all.
Threshold type

Lighthouse

Dynamic baselines that learn the metric's normal shape, including weekly seasonality and growth trend.

Looker native alerts

Static numbers you pick by hand. Nothing adapts to trend or seasonality, so the number you chose in March is wrong by June.
Per-segment thresholds

Lighthouse

Each segment gets its own baseline automatically, plus a minimum-volume filter so small segments never spam the channel.

Looker native alerts

An alert checks every row against the same threshold, unless you pin it to one specific row. Per-segment thresholds mean one alert per segment, maintained by hand.
Percentage-based conditions

Lighthouse

Percent change against a rolling baseline is a first-class condition, nothing to build.

Looker native alerts

Comparisons work on whole numbers and decimals. Percentage change needs a table-calculation workaround built into the tile.
Where alerts live

Lighthouse

Owned by the team, inventoried in one place, with a full history of every fire and resolution.

Looker native alerts

Created by an individual while viewing a dashboard, in Production mode. Ownership sits with whoever made it.
Triage in Slack

Lighthouse

Hit / Resolve / Acknowledge in the message, with metric history one click away.

Looker native alerts

A notification with the tile. No way to acknowledge, assign, or close the loop.

Looker alert capabilities described from Google Cloud’s published documentation. Looker is a trademark of Google LLC. Lighthouse is not affiliated with Google.

What we actually get to touch

A read-only service account

Its own account, not a person's. It cannot sign into the Looker UI at all: API credentials only.

Scoped to models you pick

A model set limits Lighthouse to the models you choose. Everything else in your instance is invisible to it.

No write permissions

No develop, deploy, manage models, or administer. Lighthouse cannot change LookML or create content.

Revocable in one click

Delete the service account and access ends immediately. Nothing in your Looker instance is left behind.

Full setup steps are in the Looker connection guide, and our security posture is in the Trust Center.

Common questions

Do we have to change our LookML?
No. Lighthouse reads your model through the Looker API. It never writes to Looker, never edits LookML, and never creates dashboards or Looks. If you removed Lighthouse tomorrow, nothing in your Looker instance would be different.
Does this replace Looker?
No. Your team keeps using Looker for exploration, dashboards, and analysis. Lighthouse adds the monitoring layer on top: the part Looker's native alerts don't really cover.
Will the numbers match our dashboards?
Yes, because Looker generates the query. Lighthouse doesn't reimplement your joins or filters in SQL; it asks Looker for the same measure your dashboard asks for. The one thing to watch is row-level security: if your LookML uses access filters, the Lighthouse service account needs the right user attribute values set, or it will read a filtered subset. Our setup guide covers this.
How much access does Lighthouse need?
A read-only service account, scoped to only the models you choose. It gets permission to explore and read field definitions, nothing to develop, deploy, manage models, or administer. You can revoke it in one click, and it can't sign into the Looker UI at all.
Does it work with both Looker (Google Cloud core) and customer-hosted Looker?
Yes, both. The setup differs slightly around network access: Google-hosted instances control it through Google Cloud, customer-hosted instances through the Looker admin panel. The setup guide covers each.
What does this cost us in Looker capacity?
Each check is one query through Looker to your warehouse. Lighthouse queries incrementally (pulling only the periods that changed rather than re-reading full history), so normal usage sits well inside Looker's concurrency limits, which default to around 15 to 25 simultaneous queries per account. Your instance may also have an API rate limit configured; we can pace requests to fit it.
Some of our Explores are built on PDTs. Does that matter?
Only for timing. If a metric sits on a persisted derived table, Lighthouse can detect a change once the table rebuilds, so a metric checked hourly on a nightly PDT will move once a day. Worth knowing before you set an alert expecting to hear within the hour.
How long does setup take?
About 15 minutes, and it needs someone with Looker Admin access: creating a service account, a read-only role, and an API key. The person who wants the monitoring doesn't need to do it themselves; our guide includes a message you can forward straight to your Looker admin.

Now in private beta

Put your semantic layer to work.

We’re onboarding design partners on the Looker connector now. If your business logic lives in LookML, we’d like to build this with you.

Read-only · No LookML changes · Revocable in one click