A Fabric SQL endpoint refresh fails while the lakehouse is being written

A Fabric pipeline reports an intermittent SQL analytics endpoint refresh error while several data pipelines share the lakehouse. A Fabric Community discussion raises the operational question: can downstream work proceed merely because enough time has passed? That is unsafe without a freshness check.

Distinguish activity status from endpoint state

Microsoft documents that concurrent lakehouse writes can cause lock contention and intermittent refresh failure. The activity’s output status also has distinct Success, NotRun and Failure meanings. Capture the actual output and error alongside the writing pipeline timeline; a pipeline-level status alone is too coarse.

Reduce competing refreshes

Where the data dependencies permit it, finish ingestion and transformation before one endpoint refresh at the end. Microsoft also describes a recurring refresh schedule when strict point-in-time consistency is not required. Neither option removes the need to verify that a consumer sees the right table version.

Gate the consumer on evidence

Metadata sync guidance explains background synchronization and available manual refresh controls. Use a known watermark or table version in the endpoint query before releasing a report or export. If a failed activity is allowed to continue, make that conditional on a passing freshness assertion, not on the belief that a 12-minute timeout probably refreshed enough data.

Adovo’s view

A green orchestration diagram is not a data contract. The contract is the version consumers can query at the moment they rely on it. Put that check at the boundary between lakehouse writes and business reporting.