Hi all,
I'm running into a persistent extract refresh failure on Tableau Cloud that I can't resolve despite several troubleshooting attempts.
Environment:
- Tableau Cloud
- Affected data source: Microsoft SQL Server connection, embedded in a workbook that has 4 data sources total; the other 3 refresh without issue — only this one fails.
Error received (scheduled refresh, both via failure notification email and confirmed in the Jobs view):
"TableauRuntimeException: Missing password. Incorrect username or password."
(Offline mode failure, status code = 10000)
What I've already tried:
1. Edited the affected connection on the Data Sources tab: re-entered the SQL Server credentials and selected "Embed password in connection." The connection now correctly shows "Embedded in connection" (it initially reverted to "Not embedded" right after the first save, but now persists across page reloads).
2. Clicking "Test Connection" on that data source succeeds every time.
3. Manually triggering a refresh from the Data Sources tab succeeds.
4. Deleted and recreated the extract refresh schedule/task for the workbook entirely.
5. Triggered a new scheduled/background refresh after confirming the credentials were embedded — it still fails with the exact same "missing password" error.
So the symptom is: interactive test and manual refresh both succeed with the saved credentials, but the background/scheduled job still reports missing credentials, even after recreating the refresh task.
For context: this data source was recreated recently — an older data source in the same workbook was deleted and replaced with a newly built connection to the same SQL Server, using the same server, port, and username. I'm wondering if that's relevant to how the credential object is referenced internally (e.g. the refresh task or workbook metadata still pointing to a stale connection reference from before the rebuild).
Has anyone seen this specific pattern — test/manual refresh OK, scheduled job still fails on "missing password" — and found a fix beyond re-embedding credentials? Wondering if this is a known bug tied to how a workbook's connection metadata gets bound after a data source is deleted and rebuilt.
Thanks in advance for any pointers.
#Tableau Cloud
Update / likely root cause found
For anyone following this thread, here's where things stand.
Symptom recap:
- Scheduled extract refresh failed with: "TableauRuntimeException: Missing password. Incorrect username or password" (offline mode, status code 10000).
- Test Connection succeeded every time.
- Manually triggering a refresh from the Data Sources tab in Tableau Cloud succeeded every time.
- Deleting and recreating the refresh schedule/task didn't help.
- Re-entering and re-embedding the password via the web UI showed as "Embedded in connection," but the scheduled/background job still failed with the same error.
What we found:
We opened the workbook in Tableau Desktop and went through Server > Publish Workbook > Data Sources > Edit, checking each embedded connection's Authentication setting individually. One connection (a custom SQL connection) was configured differently from the others — it did not have "Allow refresh access" (or "Embed password") selected under Authentication, unlike the rest of the data sources in the workbook, which all had one of those two options properly set.
What we did:
1. Set the Authentication option to "Allow refresh access" for that connection in the publish dialog.
2. Verified the settings for all other embedded connections as a sanity check.
3. Republished the workbook from Tableau Desktop, overwriting the existing published workbook.
4. Ran a full manual extract refresh from Tableau Cloud afterward — it succeeded.
Caveat: manual/interactive refresh succeeding was already true before this fix too, so it's not fully conclusive on its own. The real test is whether the next scheduled (unattended) refresh — run by the Backgrounder/scheduler with no interactive session — succeeds. If it does, that would confirm the missing "Allow refresh access"/"Embed password" authentication setting on that one connection was the actual root cause (the other connections had it set correctly, which is presumably why they always refreshed fine). If the scheduled refresh still fails with the same "missing password" error, we'll need to dig further into differences between the manual and Backgrounder/scheduler execution context specifically.
Will report back once the next scheduled run has completed. Posting this in case it helps anyone hitting the same "test/manual refresh OK, scheduled job fails on missing password" pattern — worth double-checking the Authentication setting per-connection in the Desktop publish dialog, not just the post-publish credential edit in the web UI.
