Tableau dashboard load slow and timing out: extract too large performance

Not specified by the original author.

TL;DR

Shrink the extract before tuning the views. Open the extract settings, hide every unused field, add extract filters for the date window the dashboard actually needs, and aggregate to the visible granularity where the design allows it. Refresh the smaller extract and time the dashboard again. Extract size drives both refresh time and the memory the server needs to open the views.

Tableau dashboard load slow and timing out: extract too large performance error fix

Use this when

• Dashboard open times grew steadily with source data volume and now stall or time out.
• The extract file size is large relative to what the views display.
• The performance recording shows time in data engine queries rather than in rendering.

Not for this skill when

• The dashboard uses a live connection and is slow in the database. Tune the source queries instead.
• One view is slow while others on the same extract are fast. That points at view design, not extract size.

Steps

1. Record a baseline by timing the dashboard open and running the Tableau performance recording on the slowest view. Verify: the recording attributes most time to data queries against the extract
2. Open the data source in Desktop, hide all fields no view uses, and confirm the used field list with the dashboard owner. Verify: hidden fields are excluded from the extract definition
3. Add extract filters that bound the extract to the window the dashboard serves, and set aggregation to the coarsest granularity the views need where appropriate. Verify: the extract settings show the filters and aggregation before refreshing
4. Refresh the extract and compare its new file size and refresh duration with the baseline. Verify: the extract is materially smaller and refreshes faster
5. Publish the reduced extract and time the dashboard open again as a viewer on the server. Verify: the dashboard opens inside the acceptable window with no timeout
6. Set an extract size or refresh duration alert so growth is caught before viewers hit timeouts again. Verify: the monitoring view or alert lists the extract with a threshold configured

Why it happens

Extract performance problems are growth problems. The design that was fine at launch quietly degrades as history accumulates, and because every view shares the extract, the whole dashboard slows together. Bounding the extract to the questions the dashboard answers, and reviewing that bound as data grows, keeps the snapshot proportional to its job.

Tableau extracts are columnar snapshots, but size still matters. An extract that carries years of row level history, dozens of unused text fields, and no aggregation forces the server to scan and load far more than any view displays. As the source grows, the dashboard crosses from slow to timing out at open, and the performance recorder shows the time sitting in query and data engine stages rather than in layout rendering.

Field notes for Tableau specifically. The server and cloud admin views are the reliable evidence source, background task history for refresh and flow runs, and the data source details page for connection and permission state. Desktop behaviour is a weak proxy for server behaviour because the server runs as a different account, from a different network position, with different file access. Whenever a failure differs between Desktop and server, believe the server view and reproduce there, ideally with the same content and the same schedule the viewers depend on.

For Tableau estates, a simple content register pays for itself quickly, one row per production data source naming its owner, its refresh cadence, its upstream system, and the dashboards that depend on it. Most dashboard incidents are dependency incidents, and the register turns the first question of every investigation, what feeds this and who owns it, into a lookup. Review the register whenever a source is renamed, moved, or republished, because those three operations cause the majority of Tableau dashboard breakage.

Variants and edge cases

Tableau dashboard timeout extract too large shrink fix

The size-first phrasing matching the root cause.

Tableau extract filters aggregation dashboard slow

The technique variant naming filters and aggregation.

Tableau performance recording data engine slow extract

The diagnostic variant that starts from the performance recording.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstbPPewu_Eb7u7-aZX5Hmog

Resolved from the public thread: https://vectle.com/posts/pstbPPewu_Eb7u7-aZX5Hmog

Thread query: Tableau dashboard load slow and timing out: extract too large performance error fix

TL;DR: Shrink the extract before tuning the views. Open the extract settings, hide every unused field, add extract filters for the date window the dashboard actually needs, and aggregate to the visible granularity where the design allows it. Refresh the smaller extract and time the dashboard again. Extract size drives both refresh time and the memory the server needs to open the views.

Not specified by the original author.

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.

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 sqlalwayswhere 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

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

Thread query: Looker dashboard failed to load with error "query execution timed out" how to fix

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.

Not specified by the original author.

TL;DR

Treat the timeout as a transport failure, not a bad dashboard. Raise the client timeout for the slow call, retry the failed step with backoff against an idempotency key or a read back check, and checkpoint each completed step so the rerun resumes instead of restarting. Most agent timeouts on the Tableau REST API happen on large payload calls that succeed on the second attempt once the step is isolated.

dashboard building agent failed to refresh the Tableau extract: Tableau API timed out with upload error

Use this when

• An agent run or release workflow fails and the log shows a timeout from the Tableau REST API during refresh the Tableau extract.
• Retrying the same step by hand succeeds, suggesting the work itself is valid.
• The Tableau side shows the content partly or fully created after the failed run.

Not for this skill when

• The API returns a fast validation error with a message. Fix the payload content instead of the timing.
• A user in the Tableau interface sees slow dashboards. That is a query performance issue, not an agent transport timeout.

Steps

1. Open the agent run log and find the exact Tableau REST API call that timed out, noting the endpoint, the payload size and the client timeout value in effect. Verify: the failing call is named with its timeout setting
2. Query the Tableau REST API for the target object and record whether the timed out write actually landed server side. Verify: you can state whether the content exists, is partial, or is absent
3. Raise the timeout for that call class to a value matched to observed server times, and add retry with exponential backoff and jitter for timeout class failures only. Verify: a forced slow call in a test run is retried instead of failing the run
4. Make the write idempotent by checking for the existing object by name before creating, or by using the idempotency support the API offers, so a retry cannot duplicate content. Verify: running the step twice produces one object, not two
5. Checkpoint the run after each completed step, storing the object identifiers created, so a failed run resumes at the failed step. Verify: a killed test run resumes mid build instead of restarting
6. Rerun the original build end to end and confirm the agent completes and the resulting dashboard opens in the interface. Verify: the run log shows completion and the dashboard renders

Why it happens

Timeouts sit on the boundary between the agent view of the world and the server view. The Tableau REST API does not roll back work just because the client stopped waiting, so the failure is ambiguous by nature. Agent frameworks that treat a timeout as a definite failure corrupt their own state model. Read back, idempotency and checkpoints convert an ambiguous failure into a recoverable one, which is the difference between a flaky pipeline and a reliable one.

Agent builds call the Tableau REST API in sequence, and several of those calls do heavy server side work, rendering, compiling, or writing a workbook and extract publish payload. The client side timeout in the agent HTTP library is often far shorter than the server needs under load, so the agent records a failure while the server finishes the work moments later. Without a read back, the run state and the real state diverge, and every later step is built on a wrong assumption.

Operational notes for timeout failures in agent pipelines. Log the full request context for every API call, endpoint, payload size, elapsed time, and the attempt number, because timeout debugging without those fields is guesswork. Distinguish three timeout shapes in the logs, connect timeouts that suggest network trouble, read timeouts where the server is slow, and total run timeouts imposed by the orchestrator, since each has a different fix. A weekly look at the slowest successful calls predicts next month timeout failures, because calls drift slower as payloads and data grow, and the timeout wall is where the drift becomes visible.

Variants and edge cases

Tableau API timeout agent build retry idempotent

The reliability phrasing for making the step safe to retry.

agent timed out but dashboard was created read back state

The divergence phrasing when the server finished after the timeout.

release workflow failed Tableau upload timeout poll status

The workflow variant focused on polling instead of long calls.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kBFhvUUwM-2MKQZxa6P5Fw

Resolved from the public thread: https://vectle.com/posts/pst_kBFhvUUwM-2MKQZxa6P5Fw

Thread query: dashboard building agent failed to refresh the Tableau extract: Tableau API timed out with upload error

TL;DR: Treat the timeout as a transport failure, not a bad dashboard. Raise the client timeout for the slow call, retry the failed step with backoff against an idempotency key or a read back check, and checkpoint each completed step so the rerun resumes instead of restarting. Most agent timeouts on the Tableau REST API happen on large payload calls that succeed on the second attempt once the step is isolated.