Refresh, schedules and the data gateway

Why refresh exists

An Import model is a cached snapshot; to stay current it must refresh — re-pull the source data into VertiPaq. Refresh is either scheduled (a recurring time-of-day plan) or triggered on demand/via API. There are limits on scheduled refreshes per day that depend on licence/capacity (Pro is more limited than PPU/Premium capacity) — exceed the business need and you either can't schedule enough refreshes or you burn capacity CU doing them.

The on-premises data gateway

When a source lives inside the corporate network (a SQL Server, a file share, an on-prem database), the cloud service cannot reach it directly. The on-premises data gateway is an agent installed on an internal machine that brokers the connection: the service sends the query to the gateway, the gateway runs it against the internal source and returns results. Two flavours matter:

• Standard (enterprise) gateway — shared, multi-user, the production choice; supports scheduled refresh and DirectQuery for many models.
• Personal gateway — single-user, tied to one person's machine; fine for personal use, a liability for shared production content.

A gateway can (and should) be clustered across multiple machines for high availability — a single-machine gateway is a single point of failure for every model behind it.

Failure modes (this is where reports go stale silently)

• Expired credentials. The stored data-source credentials expire (a rotated password, an expired secret) and every refresh through them fails — reports freeze at the last good snapshot.
• Gateway offline. The machine hosting a non-clustered gateway reboots, loses network, or the service stops — all dependent refreshes fail at once.
• Personal gateway on someone's laptop. The laptop sleeps/leaves the company and production refresh dies with it.
• Silent staleness. The worst failure: nobody notices refresh failed, and users make decisions on old data that still looks current. There is no red banner on the report.
• Refresh cap / timeout. Long refreshes hit time limits; too many scheduled refreshes hit the per-day cap or throttle capacity.
• Overlapping refreshes overloading the gateway or source.

What to watch (proofs)

• Refresh outcomes: Get-PowerBIDataset refresh-history endpoint — every model's last refresh status, time and duration; failures and long-stale models are the alert.
• Gateway inventory and health: the admin/gateways / gateway-cluster REST endpoints and the gateway management page — which gateways exist, are they clustered, and are they online.
• Personal gateways in production: gateways of personal type backing shared workspace content — a resilience red flag.
• Credential age: data sources whose stored credentials are near expiry — the pre-emptive catch before refresh breaks.
• Refresh frequency vs licence: models scheduled at or above their per-day cap, or driving heavy capacity CU (cross-reference the capacity metrics app).