Consumption pricing Looker Event definition

This page defines the concept of a Looker Event, which is the primary consumption metric used for consumption pricing models in Looker (Google Cloud core).

Note: Looker Events in the context of consumption pricing represent the execution of a query task. These are distinct from Looker events in System Activity, which are administrative and user auditing logs (such as create_dashboard, login, or delete_user) generated by the Looker server.

What is a Looker Event?

A Looker Event is a unit of measurement for consumption on your Looker (Google Cloud core) instance. It represents the value of Looker generating a query from the semantic layer, retrieving business data, and applying transformations or visual context to that data for an end user.

Internally, each Looker Event is mapped to the execution of a query task.

Definition of a query task

A query task is the internal representation of a query operation, regardless of the initiating source of the query. Examples of a query task include the following:

• Running a query in a Looker Explore or self-service Explore
• Refreshing a tile on a dashboard or a Look
• Creating a PDF of an Explore, a Look, or a dashboard tile
• A query that's run as a programmatic request by using the Looker API or a secondary query that's run as part of a merged results Explore
• An automated data delivery that uses the Looker scheduler or an alert

Each of these tasks represents 1 Looker Event. So, for example, refreshing a dashboard that includes 10 tiles generates 10 query tasks, and, therefore, 10 billable Looker Events.

A single query task covers the entire lifespan of a query operation — from the moment the query is initiated until the results begin streaming back to the initiating source.

Why query tasks are used for consumption pricing

Query tasks are uniquely positioned to measure both customer value and system resource usage in Looker for several reasons:

• Core value representation: Every core feature of Looker—including dashboards, automated alerts, scheduled reports, and visual data exploration — ultimately runs a query. Query tasks directly reflect this value-generation activity.
• Comprehensive coverage: There are no gaps in this metric. A query task is generated for every query run, regardless of how the request was initiated (for example, through the user interface, using an API, or through a scheduled delivery).
• Normalized value: The query task metric normalizes the value of data retrieval regardless of whether the results are pulled from the database or served from the internal Looker cache.
• Consistent measurement: Unlike API endpoints (which can be either scoped or unscoped, causing system-utilization differences), query tasks provide a consistent unit of measurement across all activities.

Non-billable query tasks

To ensure healthy instance performance and provide a clear, fair user experience, certain types of query tasks are excluded from the billing pipeline. Looker events generated for the following query tasks are not billable:

1. System activity queries: Queries that are run against internal instrumentation models to power Looker monitoring, usage reports, and System Activity (under the internal_model config used in helltool). This ensures that administrators can always access performance and telemetry information (such as Elite System Activity, or ESA) even if they exceed billing or governance limits.
2. Suggestion queries: Automatic queries that are sent to the database when a user types in a filter text field to generate filter suggestions. These don't represent direct, standalone value to the customer and are excluded from billing.
3. Persistent Derived Table (PDT) query executions: Queries that are run to build or rebuild PDTs. Since PDTs are a performance optimization tool recommended to improve user experience, PDT rebuild commands are not charged separately to avoid disincentivizing their use, and because they can also be triggered inline during standard query execution.
4. PDF prerender queries: Tasks that run queries to populate the cache during PDF document generation. PDF prints trigger two queries per tile (one to cache results and one to render from the cache). Only the final cache read query is counted as a billable Event, while the pre-population query is excluded.

5. Non-successful queries: Any query task that fails to return results to the user. This tasks cover database queries that result in statuses other than COMPLETE, including the following:

   • ERROR
   • KILLED
   • CACHE_ONLY_MISS
   • REJECTED (governance reject)

All other query tasks, including cache hits, remain billable to properly reflect the query traffic that's handled by the Looker instance.