Power BI Refresh Credentials Error: Reconnect Gateway

The dashboard was green on Friday and gray on Monday. No report changed, no database moved — but the overnight refresh failed on credentials, and every visual now shows last week's numbers with full confidence. Stakeholders quote stale figures in a meeting while you discover the failure from a forwarded screenshot.

Refresh credentials fail for boring reasons: a rotated database password, an expired OAuth token, a gateway machine that rebooted, a server name typed differently in two places. Power BI's messages name the category — missing, invalid, unreachable — but not the fix, so beginners click around Settings hoping. Each failed retry disables scheduled refresh further until someone performs the right three clicks in the right order.

This article gives you that order. You will learn where cloud credentials live versus gateway ones, how to re-authenticate each kind, why server names must match exactly, and how privacy levels silently block combined sources. At the end sits an operations setup — currency measures, failure alerts, and a rotation runbook — that turns credential expiry from a Monday surprise into a Tuesday task.

Two Credential Homes: Cloud Storage Versus the Gateway

Every refresh failure is a tale of two credential homes. Cloud sources — SaaS apps, web APIs, cloud databases — authenticate with credentials stored directly in the Power BI service under the dataset's Settings page. The service presents those credentials at each scheduled run with no middleman. On-premises sources — SQL Server behind the firewall, file shares, local Oracle — cannot be reached from the cloud at all, so a gateway machine inside your network holds encrypted credentials and executes the queries locally on the service's behalf.

Knowing which home your source uses decides every later click. A cloud credential problem is fixed in dataset Settings under Data source credentials with Edit credentials. A gateway problem is fixed under Manage connections and gateways (Settings gear in the page header), where clusters, connections, and their stored credentials live. Beginners waste sessions re-entering cloud credentials for gateway sources and restarting gateways for cloud sources. Read the source type first: if the data sits inside your network, the gateway owns the credential, full stop.

Credentials are encrypted where they rest and travel only to the machine that uses them. That is why fixes must happen in the same home: retyping a password in Desktop changes nothing in the service, and updating the gateway changes nothing for a cloud source. Keep a one-line inventory per dataset — source, home (cloud or gateway cluster name), and owner — and credential incidents shrink from investigations to lookups.

-- Data-currency card: the newest order date the refresh loaded
Data Currency = MAX ( Sales[OrderDate] )
-- If this date lags behind today, the last refresh failed

Reading the Failure: Missing, Invalid, or Unreachable

Power BI's refresh messages are terse but honest once you learn the vocabulary. Missing credentials means the service holds nothing for that source — typical after publishing a new dataset or reinstalling a gateway, which wipes stored credentials. Invalid credentials means it holds something stale: a rotated password, an expired OAuth token, a revoked consent. Gateway errors mean the credential exists but the road is closed: the gateway machine is offline, the source is not mapped to any cluster, or the binding names do not match.

The reading station is Refresh history on the dataset's Schedule refresh page (More options ... on the dataset). Each failed run logs its message with a timestamp, which lets you correlate: failures starting the morning after a password rotation scream invalid credentials, while failures from the first run after publish scream missing ones. Screenshot the exact message before fixing, because Edit credentials overwrites the evidence and post-mortems need the original text.

Treat repeated failures as state changes, not retries of the same event. Several failed attempts can disable the schedule, so a fix that only re-enters credentials without re-enabling and manually proving the schedule leaves the dataset green once and stale forever after. The recovery sequence is always message, credential, manual refresh, schedule re-enable, history confirmation. Skip the last two steps and you have performed hope, not operations.

-- Row-count watchdog: compare loaded rows against expectation
Loaded Row Count = COUNTROWS ( Sales )
-- Park beside a card showing yesterday's count to spot partial loads

Re-entering Cloud Credentials Without the Guesswork

Re-entering cloud credentials is a three-click errand once you stop fearing it. Open the dataset Settings page, expand Data source credentials, and choose Edit credentials beside the flagged source. For basic authentication, type the current username and password carefully — pasted secrets with trailing spaces are a classic repeat failure. For OAuth sources, complete the browser sign-in with the account that owns lasting consent, ideally a service account rather than a personal one tied to vacations and departures.

Confirm instead of assuming. After the success message, trigger a manual refresh from the Schedule refresh page and watch Refresh history until it reports success. That green entry is the only proof the credential works; the Edit-credentials dialog's own confirmation merely proves the format was accepted. If the manual run fails with the same message, the secret itself is wrong — verify it against the source system directly (log into the database with those credentials) before blaming Power BI.

OAuth deserves its own calendar entry. Tokens expire on the provider's schedule, not yours, and re-authentication is a recurring chore for sources that demand it. Note each OAuth source's expiry behavior in your dataset inventory and set reminders ahead of it. Teams that treat OAuth as configure-once meet it again as a Monday incident; teams that calendar it meet it as a Tuesday task with coffee.

-- Newest load per category exposes partial-source failures
Latest Load by Category =
MAXX (
    VALUES ( DimProduct[Category] ),
    CALCULATE ( MAX ( Sales[OrderDate] ) )
)

Gateway Setup Where the Names Must Match Exactly

Gateway setup rewards precision and punishes improvisation. Install the on-premises data gateway on an always-on machine inside the network — not a laptop that sleeps — and register it to your tenant so it appears as a cluster under Manage connections and gateways. Add a connection choosing the exact data source type, then enter server and database names copied character-for-character from Power BI Desktop's source step: SERVER\INSTANCE spellings, ports, and database names must match, because the dataset binds to the gateway source by name pair.

Authentication method is a deliberate choice, not a default to accept. Windows authentication suits domain-joined database servers, Basic suits SQL logins, and OAuth2 suits sources that federate identity — pick what the DBA provisioned, and store the provisioned account, not your personal one. Under the connection you can set a privacy level; it does not apply to DirectQuery, but for refresh-based sources it joins the privacy story covered in the next section. Grant dataset users access on the connection's Users tab where the organization requires it.

Verify binding from the dataset side, never the gateway side alone. Open dataset Settings, expand Gateway connections, and confirm your cluster appears as Running and selectable for every on-premises source in the dataset. A gateway can be perfectly healthy yet unusable to a dataset whose names differ by one backslash. When the cluster is missing here, the defect is naming or mapping, not infrastructure — resist rebooting servers for a spelling problem.

-- Gateway-bound fact check: rows per warehouse after mapping
Rows per Warehouse =
COUNTROWS ( Sales )
-- Slice by warehouse in a matrix to confirm every source bound

Privacy Levels: The Firewall That Wears a Credential Costume

Privacy levels are the firewall between your queries: None, Private, Organizational, and Public declare how freely each source's data may combine with others. A merge step joining a Private source with anything else is refused at refresh, even when both queries run perfectly alone in Desktop. The refusal is correct behavior guarding against leaking sensitive data across trust boundaries — but it arrives wearing a credential-adjacent error costume that sends teams chasing passwords.

Standardize levels per environment and document the standard. Company-internal systems that may freely combine sit at Organizational; truly public reference data sits at Public; sensitive HR or payroll sources stay Private and never merge with anything. Set levels in Desktop under File > Options and settings > Data source settings, republish, and mirror any service-side setting to match. Each change needs a refresh test, because the firewall evaluates the whole combination, not the edited source alone.

The notorious mashup variant deserves explicit handling: a single query mixing a cloud OAuth source with an on-premises source fails refresh in predictable ways. Split such mashups into separate queries per home, authenticate each through its own path, and combine with merge or append steps whose privacy levels you have aligned. Two clean queries plus one governed merge beats one clever query that cannot authenticate its halves.

Scheduled Refresh That Stays Green After You Leave

A schedule that stays green is engineered, not wished. On the Schedule refresh page, set run times that respect source availability — after nightly ETL completes, not during it — and stay within the workspace capacity's daily allotment. Enable failure notifications to the current dataset owner (verify the mailbox belongs to a living teammate after every staffing change), and keep Refresh history as your audit trail: green entries with row counts that grow as expected.

Make staleness visible where viewers look. A landing-page card showing the Data Currency measure (MAX order date) plus Days Since Load turns silent failure into a number nobody can miss. Executives will report a stale currency card faster than any monitoring mail, which makes the card the cheapest alerting you own. Pair it with a row-count card when partial loads are a risk, so half-loaded data cannot masquerade as fresh.

Close the loop with a rotation runbook. Every password rotation, OAuth re-consent, and gateway patch ends with the same three lines: update the service-side credential, run a manual refresh, confirm the next scheduled run. Store the runbook beside the dataset inventory that lists each source, its credential home, and its owner. Credential incidents then become checklist executions measured in minutes, and Monday reviews quote numbers from this morning.

-- Days since the newest loaded order: the staleness alarm
Days Since Load =
DATEDIFF ( MAX ( Sales[OrderDate] ), TODAY (), DAY )
-- Pin it beside Data Currency; anything above 1 deserves a look