SQL Endpoint lakehouse: Intermittent error in the Refresh SQL analytics endpoint activity

Hi smeetsh​,

I think there are two possibilities worth separating here.

Microsoft now explicitly documents that the Refresh SQL analytics endpoint activity can fail intermittently when another process is actively writing to or updating the underlying Lakehouse.

The reason is that the SQL analytics endpoint needs to acquire internal locks during the metadata refresh. If ingestion, a notebook, maintenance operation, or another write is holding the relevant data/metadata structures, the refresh can time out.

Microsoft documents that behavior in the Refresh SQL analytics endpoint activity guidance.

So I would first make sure your pipeline follows this pattern:

all ingestion / notebook / maintenance activity
-> wait until those writes are fully complete
-> one Refresh SQL analytics endpoint activity at the end

rather than refreshing multiple times while Lakehouse updates are still happening.

However, I would not say the lock scenario is definitely the explanation for your exact error.

Your message is:

HTTP 408 RequestTimeout
“A task was canceled”

and you are also seeing intermittent success while there is a Fabric service degradation.

That could still be a transient Fabric API/service-side timeout rather than purely Lakehouse lock contention.

A couple of things I would check:

1. Confirm that no notebook, Copy activity, maintenance task, or other writer is still touching the Lakehouse when the refresh starts.
2. Keep the retry, but use a delay/backoff rather than retrying immediately.
3. Check whether failures correlate with periods of concurrent Lakehouse writes.
4. Compare the failed timestamps with Fabric Service Health.
5. If the same 408 occurs when the Lakehouse has been completely idle for several minutes, I would capture the pipeline run ID, workspace ID, endpoint ID, timestamp and correlation/request details and raise a support case.

One other consideration is whether you need the forced refresh on every run.

Microsoft’s SQL analytics endpoint metadata sync documentation says Fabric already maintains the endpoint through a background metadata-sync process.

Under normal operating conditions, Microsoft says the lag between the Lakehouse and SQL analytics endpoint is generally less than one minute, although it can range from seconds to minutes.

So if your downstream workload can tolerate that delay, you may not need to force a refresh after every pipeline execution.

If deterministic freshness is required, then I would keep the activity, but run it once at the very end and retain the retry/backoff logic.

So my view would be:

concurrent Lakehouse writes
-> documented intermittent refresh failures

idle Lakehouse + repeated HTTP 408 failures
-> more likely worth investigating as a Fabric service/API issue

Given that you are already seeing a service degradation, I would not rule out the second case yet.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.