Tableau dashboard extract refresh failed with error data source not found fix

Not specified by the original author.

TL;DR

Republish or relink the missing source first, because the refresh is looking for a name or path that no longer resolves. Open the workbook, point each connection at the current published data source or the new file location, save, and run the refresh again before touching schedules. Once the extract builds, confirm the schedule is attached to the refreshed source.

data source not found

Use this when

• A scheduled extract refresh fails and the job history names a source that was renamed or moved.
• The workbook opens in Desktop but the server refresh cannot find the file or published source.
• A data source was republished under a new name and downstream extracts broke the same night.

Not for this skill when

• Views render but show stale numbers with no refresh error. Check the schedule and cache instead.
• The refresh fails with a database login error. Fix credentials before relinking anything.

Steps

1. Open the refresh history for the workbook and copy the exact source name the failed job tried to resolve. Verify: the named source matches a rename, delete, or move you can confirm in the content list
2. In Tableau Desktop, open the workbook, use the data pane to replace the reference with the current published data source, and check every sheet for broken field pills. Verify: no sheet shows a red pill or a missing field warning
3. For a file based source, place the file back at the path the server account can read, or repoint the connection to the new shared location and embed access correctly. Verify: the server run as account can open the file from that path
4. Publish the repaired workbook and choose the option that updates the extract connection, then run an on-demand refresh from the server. Verify: the refresh completes and the row count changes as expected
5. Reattach the original refresh schedule to the repaired source and confirm the next run time is in the future. Verify: the schedule list shows the workbook with the correct cadence
6. Open two dashboards that use the extract and compare a known total against the source system. Verify: totals match and the last refreshed timestamp is current

Why it happens

Extract refresh resolves the connection at job start. A rename, a republish that created a second source, a moved spreadsheet, or a permissions change on the folder all present as the same not found error because the stored pointer no longer resolves. Desktop can mask the problem because the analyst machine still has the file locally, while the server account does not. Relinking to the canonical published source prevents the same break on the next move.

Tableau extracts store a connection pointer, not a copy of the source definition. When a published data source is renamed, deleted, or a file based source is moved on the server, the extract job starts, cannot resolve the pointer, and reports the source as not found even though the data still exists. The background job log in Tableau Server or the refresh history in Tableau Cloud names the exact source it tried to open.

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 extract refresh data source not found after rename

The rename-specific phrasing for the most common trigger.

Tableau Server refresh failed missing data source relink

The server-side variant focused on relinking rather than rebuilding.

Tableau Cloud scheduled refresh cannot find published source

The cloud variant of the same pointer failure.

Provenance

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

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

Thread query: Tableau dashboard extract refresh failed with error "data source not found" fix

TL;DR: Republish or relink the missing source first, because the refresh is looking for a name or path that no longer resolves. Open the workbook, point each connection at the current published data source or the new file location, save, and run the refresh again before touching schedules. Once the extract builds, confirm the schedule is attached to the refreshed source.

Not specified by the original author.

TL;DR

The extract file itself or the environment trying to open it is broken, not your renewal data. Hyper cannot open the database file when the extract was corrupted by an interrupted refresh, the file path or permissions changed on the server, or the server ran out of disk or memory mid-refresh. Check the Tableau Server or Cloud background task logs, free and verify the environment, rebuild the extract cleanly, and the scheduled refresh resumes instead of silently ageing the renewal dashboard day by day.

Tableau extract refresh failed hyper unable to open database file: renewal dashboard stale for a week

Use this when

• Tableau background task history shows the refresh failing with a hyper unable to open file error
• The dashboard still opens but shows data frozen at an old date
• A server migration, disk pressure event, or interrupted refresh happened near the first failure

Not for this skill when

• Live connections to the same source work and only the published extract is stale in a different way, such as a schedule that was paused
• The source database credentials expired, which produces a connection error before the extract file is touched

Steps

1. Open the refresh history for the renewal data source in Tableau Server or Tableau Cloud and read the full job error, including any file path, and note whether every refresh fails or only full refreshes while incremental ones pass. That split separates a corrupt existing extract, which full refresh rewrites, from a broken write environment, which fails everything. Verify: the job error, file path, and full versus incremental pattern are recorded
2. Check the environment that hosts the extract. Confirm the Tableau services account can read and write the extract location, the disk has real free space rather than a quota illusion, and no antivirus or backup process is locking the extract file during the refresh window. On Tableau Cloud, check instead whether the data source was republished or its connection changed under the same name. Verify: environment permissions, space, and file locks are verified or a specific blocker is found
3. Test a manual refresh of a copy. Duplicate the data source or point a test workbook at a fresh extract build from the same source, and run it outside the scheduled window. A clean manual build proves the source data and queries are healthy and convicts the existing extract file or its schedule environment. Verify: the test extract builds successfully and returns current renewal data
4. Rebuild the production extract. Trigger a full refresh or republish the data source with a newly built extract, then confirm the dashboards data freshness timestamp advances to today and spot check renewal totals against the CRM for the current quarter so a rebuilt extract is also a correct one. Verify: the production extract refreshes and freshness and totals check out
5. Investigate what corrupted it if the test pointed at the file. An interrupted refresh from a server restart, a disk full event, or two schedules writing overlapping extracts are the usual causes, and each has a different prevention, from schedule separation to disk alerting thresholds the platform team actually watches. Verify: the corruption cause is identified or honestly recorded as unknown with monitoring added
6. Add freshness guardrails to the dashboard itself. Show the extract last refreshed time prominently on the renewal dashboard, and set a Tableau data driven alert or an external check that notifies the CS operations channel when the extract age passes one scheduled cycle, because a stale renewal dashboard fails by looking normal. Verify: the freshness display and stale extract alert are in place and tested

Why it happens

Tableau extracts are physical Hyper files that refresh jobs open, update, and replace. Interruption, disk pressure, permission changes, or file locks can leave that file or its environment in a state the next refresh cannot open, and because the old extract still serves queries, the dashboard keeps working with ageing data. The failure mode is dangerous precisely because nothing looks broken to the people reading renewal numbers every morning.

Compatibility: Tableau Server and Tableau Cloud extracts, Hyper files, background refresh jobs, and data source publishing, in current Tableau versions.

Variants and edge cases

Tableau hyper unable to open database file extract

['The verbatim phrasing. Treat it as a file and environment problem first, and resist rebuilding reports that were never broken.']

Tableau extract refresh failed renewal dashboard stale

['The staleness phrasing. Measure staleness in days and list decisions taken on the stale data, because leadership needs the impact, not only the repair.']

Tableau full refresh fails incremental works hyper

['The split variant, which usually means the existing extract or its temp space for full rebuilds is the constraint, so test full builds with realistic data volumes.']

Edge cases to work through before you close the incident:

• An extract that opens but refreshes slowly may be heading for the same failure. Track refresh duration trends, not only success and failure.
• If the source query itself changed, a rebuild can succeed and still return different renewal numbers. Always reconcile totals after a rebuild before announcing the fix.
• Tableau Cloud and Server differ in how much file system you can inspect. On Cloud, lean on job history, republish tests, and Tableau support diagnostics instead of local file checks.

Provenance

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

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

Thread query: Tableau extract refresh failed hyper unable to open database file: renewal dashboard stale for a week

TL;DR: The extract file itself or the environment trying to open it is broken, not your renewal data. Hyper cannot open the database file when the extract was corrupted by an interrupted refresh, the file path or permissions changed on the server, or the server ran out of disk or memory mid-refresh. Check the Tableau Server or Cloud background task logs, free and verify the environment, rebuild the extract cleanly, and the scheduled refresh resumes instead of silently ageing the renewal dashboard day by day.

Not specified by the original author.

TL;DR

A refresh that fails at the same time daily is a scheduled-job problem: expired source credentials, a query that times out under morning load, or an upstream job that has not finished when the refresh starts. Open the refresh history, read the actual error for the 6am run, and compare with a manual refresh. Fix the scheduled path: renew the credential the job runs under, move the refresh after its upstream dependency, or trim the query, rather than refreshing manually forever.

reconciliation dashboard shows "data refresh failed" error every morning at 6am

Use this when

• The dashboard shows data refresh failed each morning, first seen at the 6am scheduled refresh.
• Manual refresh during the day may succeed, or fail differently.
• The dashboard depends on overnight jobs, bank feeds, or a warehouse load.

Not for this skill when

• The dashboard fails at all times for all users. That is a dashboard or source outage, not a schedule issue.
• The data is correct but stale because the source system stopped sending. Follow the feed investigation, not the dashboard job.

Steps

1. Open the dashboard refresh history and record the exact error and duration for the last three 6am runs. Verify: the scheduled failure mode is stated from logs, not the banner text
2. Run a manual refresh and compare outcome and duration with the scheduled runs. Verify: you know whether the failure is schedule-specific or universal
3. Check the refresh job's data source connection and the account it runs as for expiry or permission changes. Verify: the job's identity can still read every source the dashboard uses
4. Check the timing of upstream jobs the dashboard reads, and whether they finished before 6am on the failed days. Verify: the dependency chain timing is mapped
5. Apply the matching fix, reschedule after upstream completion, renew the job credential, or optimise the failing query, and watch the next 6am run. Verify: the scheduled refresh succeeds unattended

Variant phrasings

dashboard data refresh failed every morning scheduled

The morning-failure phrasing.

reconciliation dashboard refresh error 6am job

Searching by the scheduled symptom.

Compatibility: Dashboard refresh scheduling in Power BI, Tableau, Looker, and ERP-embedded rec dashboards fed by scheduled queries.

Why it happens

Scheduled refreshes run as a service identity, against whatever state upstream jobs have reached by that hour, under the platform's heaviest load window. Manual refreshes run as you, later, against settled data, so they pass while the schedule fails, which misleads diagnosis toward the dashboard itself. The consistent clock time is the fingerprint: real data problems do not keep office hours, but job chains and credential expiries do.

Edge cases / pitfalls

• Token and credential expiries for service accounts are the classic silent cause, often exactly a round number of days after setup.
• If the upstream warehouse load slipped later over months, a refresh that once had slack now races it. Compare upstream finish times over time.
• Alert on refresh failure to the team channel; a banner noticed at 9am means three hours of decisions on stale data.

Provenance

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

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

Thread query: reconciliation dashboard shows "data refresh failed" error every morning at 6am

TL;DR: A refresh that fails at the same time daily is a scheduled-job problem: expired source credentials, a query that times out under morning load, or an upstream job that has not finished when the refresh starts. Open the refresh history, read the actual error for the 6am run, and compare with a manual refresh. Fix the scheduled path: renew the credential the job runs under, move the refresh after its upstream dependency, or trim the query, rather than refreshing manually forever.