The report was fine in spring. Now the scheduled refresh fails about one morning in three, the error mentions credentials or a timeout, and the person who built the model wants to know whether it is Power BI, SharePoint or them. Usually it is the SharePoint List connector meeting one of several published limits. Run the checks below in order before changing anything, because the first few cost nothing to check.
The limits are Microsoft’s own, from Microsoft Learn, checked on 22 October 2026. The background on why the connector slows down is in Why Power BI refreshes on SharePoint lists slow down.
Power BI SharePoint list refresh timeout checks
Start with how long a refresh takes in Power BI Desktop, because the service limits are all measured against duration. Time it again a month later and you can see the trend. A refresh that times out in the service usually fails one of the first three checks below, even when the error text talks about credentials.
| # | Check | Limit | What to do |
|---|---|---|---|
| 1 | Refresh duration in Desktop | Two hours on shared capacity, five hours on Premium | If you are near the limit, the list will cross it as it grows |
| 2 | Refresh longer than about an hour | The Entra ID OAuth token for SharePoint Online lasts about an hour | A long load can fail with a credentials error that is really a duration problem |
| 3 | Several reports reading the same list | Each one pages the list separately | Share one semantic model, or read from a copy |
Check 2 catches a lot of people out. The error says the credentials are wrong, someone re-enters them, and the next refresh fails the same way because the load still runs past the token’s life.
List shape checks for lookups and large lists
| # | Check | Limit | What to do |
|---|---|---|---|
| 4 | Connector implementation, 1.0 or 2.0 | They use different APIs | Note which one the query uses before comparing timings |
| 5 | Lookup and person columns in the default view | The v2.0 connector allows 12 join operations per query | Create a default view with fewer lookup columns |
| 6 | Items in the list | The 5,000-item list view threshold | Filter on an indexed column, or stop reading the list directly |
| 7 | URL length, if you read the list as an OData feed | About 2,100 characters | Shorten the $select, or use the list connector |
Lookup and person columns are joins on SharePoint’s side, so a list with more than a dozen of them fails on the v2.0 connector before row count becomes the issue. The workaround Microsoft gives is a trimmed default view, which then has to stay trimmed as people add columns. Our post on what breaks past 5,000 items explains where an indexed filter helps a large list and where it stops helping.
Power BI schedule refresh on a SharePoint Online list
Setting up a schedule refresh for a SharePoint Online list needs no gateway, because the list is a cloud source and its credentials sit in the semantic model settings, unless the same query also reads an on-premises source. The checks below are about what happens after the schedule is set, when it starts to fail or stops running.
| # | Check | Limit | What to do |
|---|---|---|---|
| 8 | Refresh slots per day | Eight on shared capacity, 48 on Premium, PPU or Fabric capacity | Match the slots to how fresh the report needs to be |
| 9 | Consecutive failures | The schedule is deactivated after four in a row | Re-enable it in the semantic model settings after fixing the cause |
| 10 | Inactivity | The schedule pauses after two months with no report views | Open a report, then re-enable the schedule |
| 11 | Who receives failure emails | The semantic model owner by default | Make sure that owner still works here |
Checks 9 and 11 together explain most “it stopped updating weeks ago and nobody noticed” stories. The schedule switched itself off and the email went to someone who had left.
What changes when Power BI reads a replica
If checks 1, 2, 5 or 6 are the problem, tuning the connector buys time but the list keeps growing. The longer fix is to stop Power BI reading SharePoint at all. SPSync replicates the list into SQL Server, Postgres or another database and keeps it current on a schedule you set, every five minutes by default. Power BI then connects with its database connector, by import or DirectQuery.
| Check | On the list connector | On the replica |
|---|---|---|
| Refresh duration | Grows with rows and lookup columns | Reads a table; after the first load SPSync fetches only what changed |
| Token expiry during load | Possible on a long load | The SharePoint token is no longer involved |
| 12-join limit | Applies to the query | Lookups are {col}_id and {col}_value columns on the row |
| 5,000-item threshold | Applies to unindexed queries | SQL has no list view threshold |
| Deleted items | Gone from the next refresh | Kept with sp_deleted_at set |
SPSync can also generate a reporting view per list, v_{prefix}_{list}, which joins
person columns to the shared sp_users table and leaves deleted rows out. Point the
model at the view and the merge steps in Power Query go away. Behind the schedule, a
reconcile re-checks every item weekly by default, which doubles as QA and as recovery
after an outage.
SharePoint list to SQL Server for a faster Power BI report walks through the setup with DirectQuery. Seven steps from a SharePoint list to a SQL Server table covers the database side.