hi Jamie.  Are you running cookieless (with --no-cookie) or with cookies?  The reason why I ask is I believe the default is to use cookies which stores the session info within your runas user appdata folder.  And if you have multiple tabcmd jobs running under the same runas userid, then the cookies could get "clobbered".  I found this happening a while back when I would run a tabcmd login for job1, do the refresh and whatever other activity, then job2 gets kicked off with the same info, then job1 does a tabcmd logout which "clobbers" the session info stored in the cookie and job2 ends premature.  Could this be happening in your case too?

I'm not a Tableau associate, but I do contribute a bit to the forums based on my experiences of working with the product.

I do not know if there's a limit, but I somehow doubt it.  Are you running with cookies?  you can have a look within the runas user account directory : C:\Users\runas user account\AppData\Local\Tableau\Tabcmd to see what's happening with the cookies and see if they are wiped out.  are you doing any tabcmd logout?

Here's what I do:

1. I don't run my stuff asynchronous, but rather the refreshextract runs on the server with a backgrounder and I have the script poll the status of the background task (via a loop) to ensure success and if it's not successful, then it emails an error.

2. When running with cookies, I never let the streams cross.  In other words, I use different runas userid's if the script is running at the same time.

3. It does sound familiar about the short period of being idle.  I overcome this by always specifying the password and timeout on every request even though it's part of the login command.  See this example.  It doesn't make total sense of why I should have to do this, but it has worked for me and has worked for others that I've advised on it too.

tabcmd refreshextracts --datasource "xxx" --project yyy --password %TABLEAU_USER_PASSWORD% --timeout 1800

We run the script within cygwin (so that our DW scheduler that runs on linux) can communicate with Tableau.  In other words it's bash scripting, but it could be done with powershell or python or any language for that matter.  see attached.

I know this thread is rather stale, but we are having the same struggles. Could it be that your scheduler is initiating a second session with the same credentials in order to kick off a different refresh while the first synchronous session is still in process? I'm thinking Tableau Server may only be allowing a single TABCMD session for a given user. The subsequent login may be terminating the prior connection.

kinda.  When the first session is created, a token is stored within the user's profile tabcmd folder from where-ever tabcmd is initiated.  And then if a second session is created while the first one is running, then results are somewhat unpredictable based on timing of when the first finishes and the second starts.  In any case, there's two ways around this dilemma, one is to try using --no-cookie as part of tabcmd, the other is to use an alternate id.