## TL;DR
Open the failing tile in the explore, cut the row limit and date range, and re-run to prove the query itself is the bottleneck before changing anything else. Add a required filter or an aggregate table for the heavy measure, clear the tile cache, and only then raise timeouts if the warehouse is genuinely slow. Most timeouts clear once the scan is bounded and the PDT or aggregate awareness path is used.

```text
query execution timed out
```

## Use this when
- A Looker dashboard loads slowly and one or more tiles end with a timeout message.
- The same explore runs fine with a short date range but fails on the default range.
- System Activity shows long runtimes or large scanned rows for the dashboard queries.

## Not for this skill when
- The dashboard fails instantly with a LookML or field error instead of a timeout. Use the validation skill for that case.
- All Looker pages are down for every user. Treat that as an instance or connection outage first.

## Steps
1. Open the dashboard, note which tiles time out, then open one failing tile in its explore and run it with a 7 day range and a 500 row limit to isolate the query. Verify: the trimmed query returns rows instead of timing out
2. Read the generated SQL in SQL Runner and look for a missing date filter, a fanout join across a one-to-many relationship, and a sort on an unindexed text field. Verify: you can name the clause that drives the large scan
3. Add a required dashboard filter or a sql_always_where condition on the explore so the tile cannot run unbounded, and retest with the original dashboard range. Verify: the tile completes inside the dashboard timeout window
4. If the measure is a repeated rollup, build an aggregate table or a PDT for it and point the explore at that table with aggregate awareness. Verify: the query log shows the aggregate table name instead of the raw fact table
5. Clear the dashboard cache from the admin caching controls and reload the full dashboard as a viewer, not as an editor. Verify: every tile renders and the slowest tile finishes well under the limit
6. Check the warehouse side for queued or throttled statements during the same window, and resize or schedule the load if the database was the constraint. Verify: a repeat load at peak time completes without queue delay

## Why it happens
Looker generates SQL at view time, so dashboard performance is warehouse performance. Timeouts usually come from an unbounded date range, a symmetric aggregate forced to scan a fanned-out join, or a PDT that stopped rebuilding so every tile falls back to raw tables. Raising the timeout only hides the scan cost and makes the next viewer wait longer. Bounding the query and pre-aggregating the rollup removes the work instead of tolerating it.

In Looker the dashboard itself holds no data. Every tile runs a generated SQL statement against the connection when the dashboard loads, unless a cached result or a PDT can serve it. A single unbounded tile can therefore block the whole page, and the browser shows the timeout on the dashboard even though the slow part is one explore query. Check the System Activity explore and the SQL Runner history to see the exact statement and its runtime before guessing.

## Variants and edge cases
### Looker tile query timed out on load
The single-tile phrasing users search when only one visual fails.
### Looker dashboard slow explore timeout fix
The symptom-first phrasing that pairs slowness with the timeout.
### Looker query execution timed out aggregate table
The fix-focused variant once a PDT or aggregate table is suspected.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nUAnWYggjGsk4w2DHB5pHw