Most Tableau health checks are a conversation. Someone asks the administrator what hurts, writes down the answers, and returns a document that reorganises the administrator's own opinions into slides. The findings feel right because they came from the person who already believed them.
The alternative is to measure. Every claim in this paper can be settled by a query against data Tableau already keeps about itself. Nothing here requires a workshop, a survey, or a judgement call about what "feels slow".
This paper sets out what we think a rigorous audit measures, why each area earns its place, and — the part most methodologies skip — which numbers come from Tableau's own documentation and which are ours. That distinction matters. A threshold presented as fact when it is really convention is how bad advice travels.
The instrument
A Tableau Server keeps a Postgres database about its own operation — the repository. It records every background job, every HTTP request, every view access, every extract refresh, with timings and outcomes. Nobody has to instrument anything; the platform keeps this record as it runs.
Three properties make it the right instrument for an audit.
It is complete. It records what happened, not what someone remembers happening. Administrators consistently misidentify their worst-performing content, not through carelessness but because the loud problems and the expensive problems are rarely the same ones.
It is historical — within limits worth stating. The repository's history is subject to the environment's configured retention and cleanup policies: background-job history is typically kept for around thirty days, request and event history for whatever the retention settings allow, and maintenance cleanup can shorten both. So the first thing our collector measures is the history itself, and the report states exactly how much history was available behind each metric. An audit that silently assumes ninety days of data where thirty exist is wrong in a way nobody catches.
It is read-only in practice. A properly scoped audit query changes nothing, touches no business data, and can run against a replica.
Tableau Cloud has no repository. The equivalents are the Admin Insights data sources, the Metadata API and the Activity Log — narrower, with retention Tableau sets rather than you. An honest Cloud audit says which questions it cannot answer.
What to measure, and why
1. Extract refresh outcomes
Measure: failure rate over 90 days, failures per workbook, consecutive failure streaks, and the share of total failures attributable to the worst few workbooks.
Why: failure rate alone is close to useless as a management number. What matters is concentration. In practice a small number of workbooks generate most failures, usually for one identifiable reason — a credential that expired, a source that moved, a query that outgrew its timeout. The audit's job is to name those workbooks, not to report a percentage.
Tableau's numbers: backgrounder.querylimit defaults to 7200 seconds — two
hours — after which a refresh is cancelled. Tableau Cloud suspends a refresh
schedule after five consecutive failures and does not resume it automatically.
That second fact is worth dwelling on: a suspended task stops failing, so it
disappears from failure counts. Estates get "better" by losing data.
Our judgement: we treat any workbook with three or more consecutive failures as an incident regardless of overall rate. That is convention, not Tableau guidance.
2. Backgrounder capacity and queueing
Measure: the split between time a job spent waiting and time it spent running, at the 95th percentile, broken down by hour of day.
Why: this is the single most misdiagnosed area in Tableau operations. When refreshes are late, the instinct is to blame the jobs. Usually the jobs are fine and the queue is the problem — everything is scheduled at 6am, so the last job of the batch starts at 8:40 regardless of how fast it runs. Adding hardware does not fix a scheduling problem, and it is expensive to discover that after the invoice.
Tableau's numbers: a backgrounder process is single-threaded and runs one job at a time — the concurrency of the estate is the number of backgrounder processes, full stop. Tableau's documented sizing guidance is to add backgrounder instances up to one half the number of cores on the machine. Dedicated backgrounder node roles exist but require Advanced Management.
Our judgement: we report queue wait at TP95 rather than mean, because the mean hides exactly the tail that makes people complain. Some practitioners run backgrounders above Tableau's documented half-per-core ratio; we do not treat that as a recommendation, and if an estate runs higher we say so as an observation against the documented figure rather than endorsing it.
3. Concurrency against capacity
Measure: peak concurrent users by hour against provisioned VizQL capacity, and the distance between everyday load and the observed peak.
Why: most estates are sized for a peak that happened once. Some are sized for a peak they have never reached. Both are decisions worth making deliberately rather than inheriting.
4. View load times
Measure: load time percentiles per view, separating query time from render time, and identifying the views responsible for most of the total waiting.
Why: average load time is a vanity metric. What users experience is the slow tail on the dashboard they open every morning. Separating query from render tells you whether the fix belongs to the data source or the workbook — two different teams, two different conversations.
5. Content inventory and staleness
Measure: content volume, last-access per workbook, and the storage and refresh cost carried by content nobody opens.
Why: stale content is not a tidiness problem. It consumes backgrounder slots that watched content is queuing behind. The persuasive number is never gigabytes — it is hours of nightly refresh capacity spent on workbooks with zero viewers.
Tableau's numbers: the Stale Content admin view lets you set the threshold anywhere from 1 to 120 days, which is Tableau's way of saying this is policy, not physics. Tableau can also auto-suspend refreshes on inactive workbooks after a configurable 7 to 100 days, defaulting to 32 — but only full refreshes, and only tasks running more often than weekly.
Our judgement: we use 90 days as the staleness threshold, and we treat "never opened since publication" as a different category from "not opened recently". The first is safe to retire; the second earns a conversation with its owner.
6. Schedule density
Measure: the distribution of scheduled work across the day and week, and how much of it is anchored to the same few start times.
Why: this is where the cheapest wins live. Moving a third of the 6am batch to 4am costs nothing and often removes the queue problem entirely. It is also the fix nobody proposes, because everyone assumes the schedule is load-bearing. Usually it is inherited.
7. Licence utilisation
Measure: licensed users by role against users who actually signed in, over a meaningful window.
Why: it converts directly into money, and it is the finding that gets an audit paid for. It needs care: a quarterly user is not an unused licence, and an audit that recommends reclaiming one will lose the room.
8. Permissions and governance
Measure: permission complexity — distinct grants against projects and groups — and content with no identifiable owner.
Why: complexity here is a leading indicator. Nothing breaks the day permissions get tangled; things break six months later, and nobody can work out why.
What a finding should look like
A finding that cannot be traced back to a measurement is an opinion with a confident font. Ours carry four parts, and we think any audit's should:
The measurement. The number, the window it was taken over, and the query that produced it.
The interpretation. What the number means in this estate specifically — not in general.
The comparison. Against Tableau's documented guidance where one exists, against the estate's own history where it does not, and explicitly labelled as "our convention" where neither applies.
The recommendation. What to change, in what order, and what it should move.
The third part is where most audits quietly cheat. A threshold gets stated as though it came from the vendor when it came from the consultant's habit. If you take one thing from this paper, take that: ask any auditor which of their numbers are the vendor's and which are theirs. A good one will know immediately.
What audits get wrong
Reporting averages. Nobody experiences an average. Report percentiles and distributions, and name the outliers.
Measuring the wrong window. A seven-day window misses weekly patterns entirely. A window longer than the platform's retention silently truncates. Check what history actually exists before designing the analysis.
Confusing volume with importance. The workbook with the most views is rarely the one causing the most pain.
Recommending capacity first. Hardware is the most expensive fix and almost never the first one that works. Demand-side changes — schedules, stale content, oversized extracts — are usually most of the improvement, and they are free.
Producing a document nobody can act on. A hundred findings ranked by section is a filing exercise. Ten findings ranked by what they cost is a plan.
Running it yourself
Nothing in this method is proprietary. The repository is documented, the queries are ordinary SQL, and an administrator with a read-only account and an afternoon can produce most of section 1 and section 2 unaided. We publish guides for exactly that.
What is genuinely hard to do alone is the part that has nothing to do with Tableau: comparing your estate to something other than itself, and saying out loud that a decision made three years ago is now the problem. That is usually what an outside party is for.
VizBolt Technologies · Independent Tableau environment audits [email protected] · vizbolt.com