Who Built This (and Why It Matters)
The repo is led primarily by Matt Coles, with contributions from Sean Li, Brian Cantoni, and James Baker — all Tableau insiders. These are not generic sample workbooks thrown together for a conference demo. They are built by people who know Tableau Server's internals better than most, and the workbooks reflect real operational questions that come up again and again in production environments.
That matters for another reason too. Because these workbooks are not baked into the product itself, you can customize them. Fork them, extend them, add dashboards, change the filters. The contributors even welcome pull requests back to the repo — you will need to sign their CLA and target the submissions branch, but the door is open.
The open-source angle pays off in practice, and we will come back to that.
Six Data Sources, Six Slices of Your Server
- ts_background_tasks — every background job on the server: extract refreshes, subscriptions, flows. Where to look first when jobs are failing, running slow, or piling up. Retention is a month by default.
- ts_content — full inventory of workbooks, views, and data sources published to the server. The data source you want for content audits and governance questions.
- ts_data_connections — every data connection your content is actually hitting, and from where. Essential for security reviews, migration planning, and understanding the data dependency map.
- ts_events — audit history of logins, content access, and admin actions on the server. Retention is up to six months.
- ts_users — user records, roles, licensing, and group memberships. Most common use: finding Creator or Explorer license holders who have not logged in recently enough to justify the seat.
- ts_web_requests — HTTP request logs with response times and status codes. Where the evidence lives when users are reporting slowness you cannot reproduce. Retention is one week by default — short.
For
ts_background_tasks, ts_events, and ts_web_requests, set up an incremental extract on the right key field — Increment Date for background tasks, Event Id for events, Id for web requests. Run it on a regular cadence. For ts_content, ts_data_connections, and ts_users, a live connection or full extract is fine, since those reflect current state rather than history. The README has the specific field names and filter expressions. A Real-World Example: Solving a Cost Problem with ts_background_tasks
We got a firsthand look at how powerful — and extensible — this repo can be when one of our managed services customers came to us with a costly problem.
Their data platform team noticed something troubling. Compute costs were spiking, and the culprit appeared to be uncontrolled Tableau scheduled extract refreshes hammering their query engine. The frustrating part: all of those extracts ran under the same service account, making it nearly impossible to trace which specific workbooks or data sources were responsible. They were flying blind.
What they needed was a data dump of extract execution times tied back to specific workbook authors and content. Specifically, they wanted to find unused refreshes sitting in personal folders that nobody was actively using. Their working definition of "safe to cut": any refresh linked to a dashboard that had not been viewed in the past three months, with Finance content protected.
Rather than building something from scratch, we extended the existing ts_background_tasks workbook by adding a custom "Background Task Durations" dashboard on top of the same underlying data source. It surfaced extract start and end times with full author and workbook attribution. We published the dashboard directly to their Tableau Server environment.
Within a week, the customer had what they needed to start their cull.
The point is not the specific dashboard we built. It is that we did not have to start from zero. The hard part — getting around the PostgreSQL repository, building the right joins, handling the data model — was already done.
We just added the layer their specific situation required. That is the open-source angle paying off in practice. Because the foundation is forkable, a customer-specific question becomes a one-dashboard build instead of a one-quarter project.
Getting Set Up
Once that is done, the setup is straightforward:
- Download the appropriate version of the workbook from the GitHub repo. The compatibility chart in the README maps Tableau Server versions (2019.1 through 2023.1+) to the right file version.
- Open the workbook in a compatible version of Tableau Desktop.
- Set the Tableau Server parameter — used to build the URL action hyperlinks throughout the workbook.
- Set the Timezone parameter — datetime fields with "(local)" in the name will convert to your local timezone; everything else is in UTC.
- Follow the retention notes above for each data source.
- If you need row-level security, the workbook includes a built-in User Filter calculation. Edit it as appropriate and add it as a data source filter set to "true."
- Publish the workbook to Tableau Server. In the publish dialog, click Edit under Data Sources and pick Publish separately for the workbook's data source. That puts the dashboards and a standalone published data source on Server, which means you and your colleagues can connect to that data source and build other workbooks on top of it instead of repeating the SQL spelunking. That is how this turns from one admin's tool into your whole organization's operational lens on Tableau.
The Community Insights repo closes that gap, and because it is customizable, it can grow with your specific needs rather than the generic ones.
If you have used these workbooks in your environment, or extended them to solve a problem we have not covered, we would love to hear about it. And if you are hitting operational questions about your Tableau Server environment that you cannot get answered through the standard UI, reach out — this is the kind of problem we love.
Special thanks to Matt Coles and team for building and maintaining this resource for the Tableau community.