Surviving the refresh calendar

Non-production tenants are refreshed from production on a calendar: preview weekly, sandboxes on their own cadence, cadence practitioner-observed. A refresh copies production over the tenant, and the copy does not preserve the pieces an extraction depends on. The integration account, its credentials, the scheduled jobs, and the endpoint can all change or reset in the copy.

A pipeline that treats its tenant as stable breaks on the refresh and fails quietly: the account is disabled, the run does nothing, and the first sign is a stale warehouse a day later. The refresh is predictable; the outage does not have to be.

The owned pipeline expects the calendar. It health-checks the connection before each run, a trivial authenticated call, and gates the extraction on the result: pass and proceed, fail and alert instead of running blind. When a refresh has reset the account, the check catches it in seconds, and re-establishing credentials and re-registering the schedule becomes a runbook step, not an investigation.

-- the pre-run gate: prove the account can still read before extracting
-- 1. authenticated health call returns the current worker count
-- 2. if it errors or returns zero, halt and alert, do not run the load
-- 3. on a known refresh date, re-establish credentials first, then check
SELECT CASE WHEN health.worker_count > 0 THEN 'proceed' ELSE 'halt: refresh?' END
FROM integration_health_check health

Paired with the completeness check on the integration security page, the pipeline fails loudly at the door instead of landing an empty extract. The refresh calendar becomes one more input the pipeline knows, and the day-after stale warehouse stops happening.