Operation OneLake Write via Redirect in Lakehouse

[elissandrorosa]

Hello!

Can someone explain in more detail what the OneLake Write via Redirect operation in a Fabric Lakehouse includes? It appeared in the Fabric Capacity Metrics app, but I couldn't trace its origin. It doesn't have an assigned user, the duration is zero, but it had a significant CU consumption.

Thanks friends.

[v-achippa]

Hi @elissandrorosa,

Thank you for reaching out to Microsoft Fabric Community.

Thank you @Vinodh247 and @Shahid12523 for the prompt response. 

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user for the issue worked? or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa

[elissandrorosa]

Hi. Yes, I can understand what it means, but I have difficult diagnosing the source to take action.

Thanks. 

[v-achippa · Accepted solution]

Hi @elissandrorosa,

OneLake Write via Redirect shows up when fabric is writing data blocks directly into OneLake storage. These are often background system writes like table updates, materialized view refreshes or pipeline/dataflow outputs. That is why they appear with no user and 0 duration but still consume CU.
The best way to diagnose the source is like:

• In the Capacity Metrics app, filter on the operation and use the Timepoint details view, it will show the workspace and item like the lakehouse, pipeline, dataflow, etc., that triggered the writes.
• Cross check the same time window in the Monitor hub to see which pipeline, notebook or dataflow was running.

If there is very high CU usage compared to the amount of data written, it may be because of too many small files being created. Please try to consolidate these into fewer or larger files or running the delta table optimization can help reduce this.

If the issue still persists please consider raising a support ticket for further assistance. To raise a support ticket, kindly follow the steps outlined in the following guide:

How to create a Fabric and Power BI Support ticket - Power BI | Microsoft Learn

Thanks and regards,

Anjan Kumar Chippa

[Shahid12523]

OneLake Write via Redirect is an internal Fabric Lakehouse operation that quickly “redirects” writes to an existing data location. It shows zero duration but consumes CUs because Fabric handles metadata, indexing, and caching behind the scenes. It usually has no user assigned and comes from internal tasks like incremental writes, materialized view updates, or data optimizations.

[elissandrorosa]

Hi. Thanks for your reply. I understand. 

[Vinodh247]

"OneLake Write via Redirect" refers to storage write operations that fabric offloads directly to OneLake storage. These are often system generated and may not reflect user activity. Even with no assigned user or duration, they can rack up CU usage, especially when bugs or autogenerated staging artifacts are in play. If you're seeing significant consumption, it’s time to investigate background artifacts.

What “OneLake Write via Redirect” Means?

The term "via Redirect" refers to how OneLake accesses data. It uses redirect calls, sending clients directly to underlying Azure storage instead of proxying through additional layers. Fabric charges CU for every read/write request, whether via redirect or proxy, based on standardized rates:

• Write via Redirect: 1,626 CU secs per 10,000 operations per 4MB block

These rates apply uniformly to both "redirect" and "proxy" access paths, per Microsoft’s documentation

Why there is no user, no duration, but high CU?

This typically indicates background system-level operations, those Fabric runs on the Lakehouse for internal management, not userdriven activities. They can trigger a lot of write operations disguised as system maintenance.

What you can try:

1. Investigate autogenerated artifacts in OneLake (especially under dataflows staging), even if staging is not enabled.
2. Clean up unnecessary or stale tables via script (Python notebooks worked for others).
3. Use the Timepoint Details view in the Fabric Capacity Metrics App to narrow down when and where these operations spike
4. Escalate to Microsoft support with CU telemetry and logs if cleanup doesn’t resolve the issue.

Please 'Kudos' and 'Accept as Solution' if this answered your query.

[elissandrorosa]

Hi. Thanks for your reply. 

I understand. My biggest difficulty is being able to capture situations that trigger this operation, in order to try to optimize or fix something that is consuming my capacity.