The Tableau Cloud Activity Log, explained: what it records and how to actually use it

Administrators who came up on Tableau Server had one enormous advantage: the repository. Whatever question the day produced, there was a database underneath the platform that could answer it. Tableau Cloud took that database away — and quietly replaced it with something that, used properly, answers most of the same questions and a few new ones. It is called the Activity Log, most platform owners have never opened it, and it is the foundation of every serious operational practice on Tableau Cloud. This guide explains what it is, what it records, how the delivery actually works, and how to get oriented once the events start landing.

What the Activity Log is

The Activity Log is Tableau Cloud's operational event stream: background jobs, view sessions, sign-ins, content access, exports, and configuration changes, emitted as JSON events. When a refresh runs, an event records it. When someone opens a view, signs in, exports data, or changes an authentication setting, events record those too. It is the closest thing Tableau Cloud has to the Server repository admins used to query directly — except it arrives as a feed, not a database.

That distinction shapes everything downstream. A database sits still and waits for your query; a feed keeps moving and lands wherever you point it. You do not query the Activity Log in place. You land it somewhere — and then the database you query is one you own, on your side of the fence, with whatever retention you decide to keep. For administrators used to being issued a fixed window, that last part is the quiet upgrade: the feed's history becomes yours to accumulate.

It also means the Activity Log rewards exactly one kind of organization: the kind that sets up the pipeline before the week it is needed. The event stream only helps with questions asked of data that was already being collected when the interesting thing happened. Turning it on the day something breaks answers nothing about yesterday.

How you get it

The Activity Log is delivered to an S3 bucket you configure — the S3 delivery is part of Tableau's Advanced Management. From S3 it can be ingested into whatever your organization already uses for logs — commonly Splunk, since the security team usually got there first and the pipeline patterns are well worn. If your organization already ships CloudTrail or application logs from S3 into a log platform, this is the same shape of work, and often the same team's afternoon.

Delivery cadence depends on your tier; on many tenants files arrive in periodic batches rather than continuously. That sounds like a footnote. It is not — it matters later, when you schedule anything that reads this data. A report or alert that runs at 06:00 sharp against a feed whose files land at 06:40 is confidently analyzing yesterday. The licensing tiers and access paths are laid out in more detail in our guide to auditing a Tableau Cloud site.

What it records

The event families that matter operationally:

• Background jobs. Every refresh and system job with its lifecycle states — queued, started, succeeded, failed. This is the raw material for refresh health and queue analysis: failure patterns, runtime growth, and how long jobs sit waiting before they run.
• View activity. Sessions and view access — the raw material for performance and adoption questions. Which content is actually used, by how many people, and what happens to that usage over time.
• Sign-ins. Authentication events with outcomes — your security signal. Successes, failures, and the patterns in each.
• Content and configuration events. Exports, permission and authentication configuration changes, capacity changes. The audit trail for "what changed, and when."
• Storage samples. Periodic site storage usage readings — the series that turns storage from a surprise into a curve you can read.

Notice what these five families have in common: each one is the evidence base for a question you are currently answering by feel. Is refresh health getting worse? Is anyone using this dashboard? Did sign-in failures spike last Tuesday? The events to answer all of these are already being emitted. The only question is whether anything of yours is reading them.

Getting oriented in Splunk — one starter query

Assume the feed lands in index=tableau with a sourcetype for the Activity Log. The temptation at this point is to go straight to a dashboard — refresh health over time, usage by project, the works. Hold off. Dashboards encode assumptions, and the first session with a new data source should be spent checking assumptions instead: what actually arrives, what shape it has, and when it lands. One query, before anything else.

What does your tenant actually emit?

index=tableau | stats count by eventType | sort -count

Every tenant is different: identity setup, tiers, and features all change which events you receive. Run this before trusting any dashboard built on assumptions. The output is your tenant's actual vocabulary — the event types you really get, ranked by volume — and it is the first thing to check when a chart built from someone else's blog post comes up empty. Then turn to refresh outcomes: a rising share of failed states is the first thing to investigate.

The three mistakes everyone makes first

Assuming every event type exists in every tenant. They don't — verify. Tier, identity configuration, and enabled features all change what your feed contains. The query above exists precisely so that you build on what your tenant emits, not on what a document or a colleague's tenant suggested it might.

Treating event timestamps and arrival times as the same thing. An event carries the time it happened; your log platform records the time it arrived. On batched tiers these can differ by hours. Aggregations by event time are correct; schedules keyed to arrival are correct; mixing the two produces reports that are subtly, consistently wrong.

Reading averages where the problem lives in the tail. Queue waits and load times are percentile problems. An average blends the fine mornings with the bad ones and reports that everything is roughly okay; the people waiting in the slow tail disagree. Ask Splunk for percentiles rather than averages — it is one function call, and it is where the truth lives.

What the Activity Log won't tell you

Two honest limits. First, some things are simply not logged — cached view opens, some API-driven exports — so treat usage numbers as a floor rather than an exact census, and say so when you present them. Second, and more consequential for operations: native alerting on this data is minimal — a storage email at the threshold. The feed is rich; the alerting layer on top of it is what Tableau largely leaves to you. The events that would have warned you about a failing refresh streak or a climbing storage curve are all in the data, arriving on schedule, and nothing built into the platform is reading them on your behalf.

VizBolt for Splunk is that layer — fifteen Predictive Alerts reading this same feed in your own Splunk. → VizBolt for Splunk