Why Tableau quietly suspends your extract refreshes — and how to see it coming

There is a category of platform problem that announces itself, and a category that does the opposite. A refresh failure belongs to the first: it shows up in job lists, it emails owners, it leaves a red mark. A refresh suspension belongs to the second — and it is the direct, documented consequence of the first. Tableau Cloud suspends a scheduled refresh after repeated failures, and from that moment the task stops producing any signal at all. This guide covers why suspensions happen, how to find the ones you already have, and why the pattern that precedes every suspension is visible in advance — if anything is counting.

The mechanic nobody reads the fine print on

Tableau Cloud suspends a scheduled refresh after a run of consecutive failures. The suspension is the dangerous part, not the failures: a suspended task stops failing, so it disappears from failure counts. The metric a team most commonly watches — failures per day — actually improves at the exact moment the situation becomes worse. Meanwhile the dashboard keeps rendering, with data that quietly stops updating. Nothing looks broken, because nothing is running.

That is why most teams discover a suspension weeks later, when a number looks wrong in a meeting. Someone notices the quarter's figures have not moved, someone else checks the extract's last refresh date, and the archaeology begins. The gap between "Tableau suspended the schedule" and "a human noticed" is pure exposure — decisions made on stale data with full confidence — and its length is determined entirely by whether anything was watching.

Why refreshes start failing in the first place

The usual suspects, in rough order of frequency:

• Expired or rotated credentials on the data source. The security team rotates a service account password on schedule; the data source embedded the old one; the next refresh fails.
• Upstream schema changes. A renamed column, a dropped table, a changed type — invisible to Tableau until the refresh reaches for it.
• Network path changes to on-prem sources, including Bridge client issues. The route the refresh relies on stops existing, or the Bridge machine it depends on has a bad week.
• Timeouts as extracts grow. The refresh that comfortably fit its window at one size stops fitting after a year of growth.
• Permission changes on the source side. The account can still sign in, but can no longer read what the extract needs.

Note what these have in common: none of them are Tableau failures exactly — they are changes elsewhere that Tableau is the first to trip over. This is why the failure looks confusing from inside the Tableau UI: the cause usually lives in a system whose owners have no idea a refresh depends on them.

How to find already-suspended tasks today

In Tableau Cloud's UI, the Jobs and Tasks pages surface suspended schedules — if you know to look, and if looking is part of someone's routine. The faster question is the inverse: which extracts have not refreshed lately? Absence of runs catches both suspended tasks and tasks that have quietly stopped mattering. With the Activity Log landing in Splunk, it is a short exercise: list each scheduled task by the last time it actually ran, and read that list against what you know of each task's schedule. Tasks whose last run is far older than their schedule are either suspended or abandoned — both worth a look. A daily task last seen eleven days ago is a finding regardless of which explanation applies: either Tableau suspended it and nobody noticed, or it was retired informally and is still occupying a schedule slot and someone's mental model. (If the Activity Log is new to you, start with our guide to what it records and how to query it.)

The pattern before the suspension

Suspensions are the end of a streak, which means they are visible in advance by definition: one failure is noise, two is a pattern, three is a countdown. Every suspension that has ever surprised a team was preceded by a run of consecutive failures, each one individually logged, each one individually ignorable.

Walk through how it actually plays out. Monday morning, a refresh fails — the service account's password was rotated over the weekend. Nobody looks; one failure in a fleet of tasks is background noise. Tuesday it fails again, identically. Wednesday, again. Each failure is logged, each appears in the day's totals, and each is individually unremarkable — Wednesday's failure count for the whole site might even be lower than last week's. The task is three runs into a countdown, and every metric anyone watches says things are normal.

The reason teams get surprised is that the obvious metric asks the wrong question. The teams that catch suspensions early are watching streaks, not daily totals — a different question than most failure dashboards answer. Total failures per day mixes every task together and drowns a steady streak in one noisy morning's spike. A task on a three-failure streak is not having bad luck; it is broken in a way that will not fix itself, and the platform's own suspension rule is already counting.

What to do when you catch a streak

First, check the failure reason on the task's recent jobs — the error text usually points straight at one of the five causes above. Fix the credential, schema, network, or permission cause at its source; for timeouts, the fix is usually making the extract smaller rather than hoping the window grows. Then re-run the task manually: one clean run is the only proof that the fix took, and the only thing that stops the countdown.

It is worth telling the owner, too. The person whose dashboard depends on this extract found out nothing when it started failing and would have found out nothing when it suspended; a one-line message closing the loop costs nothing and builds exactly the reporting habit — "my numbers look stale, can you check the task?" — that catches the next streak earlier.

And if the task is one nobody owns anymore — the owner left, the project wound down, the dashboard's audience evaporated — retire it deliberately instead of letting it suspend accidentally. A suspension is the platform's way of retiring a task without anyone deciding to; an audit of task ownership prevents most of these by making the decision happen on purpose, once, instead of by neglect, repeatedly.

VizBolt's Refresh Suspension Risk signal counts the streaks for you and names the date — before Tableau goes quiet. → VizBolt for Splunk