If your extract refreshes have started sitting in Pending longer than they used to, and nothing about your schedules changed, the platform may have moved underneath you.
I run a congested Tableau Cloud site. When queue times drifted up this summer I went looking for what I had broken, and found I had broken nothing. In Tableau 2026.1 the default number of extract refreshes a new site can run at once dropped from 25 to 10.
In this post
Pending is a queue state, not an error. Every slot that could run your job is busy. Tableau targets a 15 minute start, so past that you are over capacity rather than broken.
2026.1 cut the default from 25 to 10. New sites on Advanced Management, Tableau+ and Enterprise now get ten concurrent extract refreshes instead of 25. Existing sites were not necessarily rebased, so two sites on the same plan can behave very differently depending on when they were created.
Two ceilings, and they fail differently. Concurrency makes refreshes late. The daily runtime budget makes them not happen at all: at 100 percent, Tableau cancels rather than delays. The second one is the one that gets misread as a scheduling bug.
You cannot prioritise your way out. Priority tiering is the standard Tableau Server answer to contention, and it does not exist on Cloud.
What is left is timing and volume. Spread the start times, check real durations before rebalancing, and watch the budget rather than the calendar.
Pending is a queue state, not an error
Nothing is wrong when a job is Pending. Every slot that could run it is busy. The Jobs page tooltip shows how long a job has been queued, and Tableau flags one as running late using a rolling average of its recent durations. The stated target is for a job to start within 15 minutes (opens in a new tab).
The failure mode arrives later. A refresh that queues long enough can run past the 120 minute ceiling (opens in a new tab) and get killed, and a task that fails five times consecutively is suspended. A capacity problem reaches your inbox disguised as a reliability problem, which is why people go looking for a broken data source instead of a full queue.
What changed in 2026.1
Sites on Advanced Management, Tableau+ or Enterprise used to get 25 concurrent extract refreshes. From May 2026, new sites default to 10 (opens in a new tab). That is a 60 percent reduction in how much work a site can do at once. If your refresh calendar was tuned against 25 slots, the same schedule now queues two and a half times deeper at peak.
I should be honest about the limits of my own evidence here. I noticed this because my queue times got worse, but my site also picked up a batch of new workbooks over the same period. The documentation change is a fact; the claim that it explains what I saw is an inference, and yours may have a different cause. Check your own concurrency setting before rebuilding your schedule around this.
Two ceilings, and they fail differently
Two separate limits apply, and confusing them wastes a lot of time.
Concurrency is how many extract refreshes run at the same time. The published limits (opens in a new tab) are 15 per tenant on Tableau Cloud Standard, 25 plus one per ten Creator licences on Enterprise, 50 plus one per five Creators on Cloud Plus and Tableau+, and 15 per unit for Viewer Blocks. The same page sets the 120 minute runtime maximum and a 20 GB memory ceiling. Hit either of those and the job is killed, not queued.
The daily runtime budget is the one that catches people out. A site gets eight backgrounder hours per Creator licence per day (opens in a new tab). Admins get email at 70, 90 and 100 percent of it, and at 100 percent Tableau states that "any future extract refreshes are canceled." The budget resets at 24:00:00 UTC.
Worth sitting with, because it is the distinction that matters operationally: concurrency makes refreshes late, and the runtime budget makes them not happen at all. A cancelled refresh looks nothing like a slow one from the outside, and it is easy to read as a scheduling bug.
You cannot prioritise your way out
On Tableau Server, the standard answer to contention is priority. Give the important extracts a better priority number and they jump the queue. Most of the advice you will find about refresh contention was written for Server, and a good share of it quietly assumes this.
That option does not exist on Cloud, and the documentation (opens in a new tab) is blunt about it:
The priority for tasks and schedules can't be adjusted in Tableau Cloud.
This is the part worth internalising, because it invalidates a lot of otherwise reasonable advice. On Tableau Cloud the only variable you actually control is when things run.
What is left is timing and volume
Spread the start times. The most common shape of this problem is dozens of extracts set to the top of the same hour, usually 6 AM, because that is the default people reach for. Ten of them run and the rest queue. Moving tasks across the surrounding hours costs nothing and is the single highest-leverage change on most sites.
Check real durations before you rebalance. Refresh durations vary more than people expect, so an even spread of tasks is not an even spread of load. Six 90 second extracts and one 40 minute extract in the same hour is not a balanced hour. Admin Insights carries per-job durations if you want the real numbers rather than an assumption.
Reduce the work, not just its timing. Incremental refreshes where the data model allows them, and a genuine audit of which extracts still need to be daily. On most sites that have been running a few years, some meaningful share of the refresh calendar is feeding dashboards nobody opens.
Watch the budget, not just the calendar. Because the daily budget cancels rather than delays, it is the one that will surprise you. If you are anywhere near it, adding a refresh does not make things slower. It makes something else not run.
Where this leaves you
If refreshes are queuing on Tableau Cloud today, the honest summary is that the platform gave you fewer slots than it used to, you cannot prioritise your way around it, and the levers you have left are timing and volume.
That is a scheduling problem, which is a solvable one. It is mostly tedious rather than hard: the work is finding which hours are actually full, and moving things a task at a time through a UI that was not built for it. If you would rather see the whole calendar at once, that is the gap Stagger exists to close.