In Azure ML compute in US East 2 - terminal and notebook lag and stall constantly

Question

In Azure ML compute in US East 2 - terminal and notebook lag and stall constantly

Mathieu Longtin 116 Microsoft Employee

Our compute in AML US East 2, when using in terminal mode or in Jupyter notebooks, constantly stall for multiple seconds. You start typing a command and it freezes for 4-5 seconds. This happens multiple times per minute. This does not happen with compute in Canada or UK. My ping time to US East 2 is 50ms and other network connections to the same region do not display that issue. This happens on a freshly booked compute with nothing else running on it.

Mathieu Longtin 116 Reputation points Microsoft Employee

2026-06-05T14:42:58.4066667+00:00

This has been going on for months btw.
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-06-05T14:43:11.57+00:00
Hi @Mathieu Longtin

Sorry to hear that you're experiencing lag and stalls in the Azure ML compute terminal and notebooks in East US 2.

This type of issue can sometimes happen due to:

High compute node utilization

Kernel/session instability

Browser/WebSocket latency

Underlying VM health or temporary regional capacity issues

Long-running background processes consuming CPU or memory

Here are a few things you can try from your end:

Restart the notebook kernel and reconnect the compute instance

Stop and start the compute instance completely

Check CPU and memory utilization under the compute metrics

Try accessing the notebook in an InPrivate/Incognito browser session

Verify whether the issue occurs across all notebooks or only specific ones

If possible, test with another compute instance size or region

Also, please confirm:

Which VM size you are using?

Whether the issue occurs continuously or during specific times.

If any recent package installations or custom startup scripts were added.

If the issue continues after restarting the compute, it may require deeper investigation from the backend team.

Please keep us updated with the observations, and we’ll try our best to assist further.

Thank you!
Mathieu Longtin 116 Reputation points Microsoft Employee

2026-06-08T14:11:39.8366667+00:00
This happens on a freshly booted ML compute instance with nothing else running than a Jupyter lab terminal

It happens on all terminals, continually. You type and all of sudden nothing comes out for a few seconds, then it's okay for a few seconds, then it freezes again.

Standard_E4ds_v5

This happens on old and fresh ML compute.

The only consistency seems to be US East 2, we have multiple workspaces there, and they all exhibit the problem. workspaces in other regions are all much smoother
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-06-09T18:41:23.85+00:00
Thanks for the detailed information, this is very helpful.

From what you’ve described, this pattern does not look like a typical compute sizing or workload issue, especially since:

It happens on a freshly booted instance

Only a Jupyter terminal is running

It is consistent across multiple workspaces

And is limited to the US East 2 region

This strongly points toward a regional or infrastructure-level issue rather than something specific to your compute instance or configuration.

A few things to consider:

Region-specific behavior Since the issue is reproducible across multiple workspaces in US East 2 but not in other regions, this suggests there may be latency, backend load, or networking issues affecting that region’s Azure ML compute infrastructure.

Jupyter terminal lag pattern. The behavior you described (input freezing for a few seconds, then catching up) is often seen when there is:

Intermittent network latency between browser and compute

Or backend I/O throttling / control plane delays

Not related to VM size Using Standard_E4ds_v5 should be sufficient for terminal usage, and since the problem occurs even when idle, it’s unlikely to be CPU or memory pressure.

What you can try as a workaround:

Test the same setup in another nearby region (for example: East US or Central US) to confirm the difference

Try connecting via a different network (to rule out client-side latency)

If possible, open browser developer tools and observe if there are delayed WebSocket responses when the freeze happens

At this point, based on your observations, this appears to be a region-specific service degradation rather than expected behavior.

Please continue monitoring, and if you notice any pattern changes (time-based spikes, specific hours, etc.), sharing that detail would help narrow it down further.

Thank you!
Mathieu Longtin 116 Reputation points Microsoft Employee

2026-06-10T13:30:44.0166667+00:00

I'm already using other regions as well, this behavior is not in other regions, as noted in my previous message. I have to use US East 2 as well, I can't not use it. So can you investigate this properly instead of feeding my answers to an AI so it repeats what I said?
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-07-07T18:24:29.2766667+00:00

Hello @Mathieu Longtin

Please let me know if the issue persists after these checks. If you have any remaining questions or need additional details, I’ll be glad to provide further clarification or guidance.

Thankyou!
Manish Deshpande 8,055 Reputation points Microsoft External Staff Moderator

2026-07-14T20:10:54.79+00:00
Hi Mathieu,

Thanks for your patience here and you're right to push back. You've already done the isolation work that matters, so let me skip the generic checklist and focus on where this actually points and how to get it to the team that can fix it.

What your evidence already tells us

The pattern you describe type, freeze for a few seconds, then it all catches up in a burst, on a freshly booted instance running nothing but a terminal is the signature of backpressure on the notebook/terminal WebSocket path, not CPU, memory, or VM size.
The strongest signal is that it reproduces across multiple workspaces and multiple compute instances, but only in East US 2, while every other region is smooth. That combination effectively rules out your compute, your configuration, and your VM size, and points at something region-scoped in the Azure ML notebook/terminal connectivity tier for East US 2.

So to be clear: This isn't something you'll fix by resizing, restarting, or switching browsers. I don't want to send you around that loop again. The one thing worth confirming is where the stall sits (backend vs. the WebSocket path in between), because that's what makes the escalation land quickly.

A few quick things to rule out (fast, and each one strengthens the escalation)

Service Health / Resource Health. Portal > Service Health >Service issues (and Resource Health on the workspace), filtered to East US 2. This confirms whether there's already a known regional event for Azure ML if so, it ties your case straight to it.

Confirm it's the relay, not the VM.
During a freeze, open F12 > Network > WS and watch the terminal/notebook socket.
If the frames stall while the box is idle, that's the backend path, not your compute. Cross-check by running top (compute should stay idle) and by opening a terminal via SSH or VS Code Remote instead of the Studio UI. If SSH is smooth but the Studio terminal still stutters, that isolates it to the Studio notebook/terminal service path in that region.

WebSocket egress from your network. Jupyter/terminal rely on open WebSocket connections to *.instances.azureml.net and *.instances.azureml.ms. A corporate proxy or firewall that buffers or throttles WebSocket traffic to the East US 2 endpoints specifically can produce this same type-then-burst stall. Since a different region means different endpoint hosts, this is the one client-side factor that region-to-region comparison doesn't fully eliminate — worth a quick check with your network team, and easy to test from an off-corp-network connection.

Session backpressure (unlikely in your case, noting it only so it doesn't get raised again): too many lingering notebook/terminal sessions on a compute can cause the same typing lag, but that clearly doesn't apply on a fresh box. You can confirm via Manage active sessions in the terminal toolbar. Ref: Manage notebook and terminal sessions.

How to get this properly investigated

Because this looks like a regional, service-side pattern, the Q&A thread alone can't resolve it — it needs the Azure Machine Learning team to look at the East US 2 notebook/terminal infrastructure. We need some details:

3–5 freeze timestamps in UTC, with workspace + compute names and region (East US 2),

the WebSocket timing capture (F12 → Network → WS) during a freeze,

confirmation that top/vmstat shows the instance idle during the stall,

whether SSH / VS Code Remote to the same instance is smooth while the Studio terminal isn't,

whether the stall persists from a network path outside your corporate proxy.

https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-compute-sessions?view=azureml-api-2

https://learn.microsoft.com/en-us/azure/machine-learning/how-to-access-terminal?view=azureml-api-2

https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-compute-instance?view=azureml-api-2&tabs=python

https://learn.microsoft.com/en-us/azure/machine-learning/concept-compute-instance?view=azureml-api-2

https://learn.microsoft.com/en-us/azure/service-health/overview

Thanks.
Manish Deshpande 8,055 Reputation points Microsoft External Staff Moderator

2026-07-16T00:49:08.9233333+00:00

Hello Mathieu
I just wanted to kindly follow up to check if you had a chance to review my earlier response. I hope the information shared was helpful. Please feel free to reach out if you have any additional questions or need further clarification.
Manish Deshpande 8,055 Reputation points Microsoft External Staff Moderator

2026-07-22T22:36:19.6066667+00:00

Hello Mathieu
I just wanted to kindly follow up to check if you had a chance to review my earlier response. I hope the information shared was helpful. Please feel free to reach out if you have any additional questions or need further clarification.

1 answer

Your answer

Mathieu Longtin 116 Reputation points Microsoft Employee

2026-06-05T14:42:58.4066667+00:00

This has been going on for months btw.
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-06-05T14:43:11.57+00:00

Hi @Mathieu Longtin

Sorry to hear that you're experiencing lag and stalls in the Azure ML compute terminal and notebooks in East US 2.

This type of issue can sometimes happen due to:

High compute node utilization

Kernel/session instability

Browser/WebSocket latency

Underlying VM health or temporary regional capacity issues

Long-running background processes consuming CPU or memory

Here are a few things you can try from your end:

Restart the notebook kernel and reconnect the compute instance

Stop and start the compute instance completely

Check CPU and memory utilization under the compute metrics

Try accessing the notebook in an InPrivate/Incognito browser session

Verify whether the issue occurs across all notebooks or only specific ones

If possible, test with another compute instance size or region

Also, please confirm:

Which VM size you are using?

Whether the issue occurs continuously or during specific times.

If any recent package installations or custom startup scripts were added.

If the issue continues after restarting the compute, it may require deeper investigation from the backend team.

Please keep us updated with the observations, and we’ll try our best to assist further.

Thank you!
Mathieu Longtin 116 Reputation points Microsoft Employee

2026-06-08T14:11:39.8366667+00:00

This happens on a freshly booted ML compute instance with nothing else running than a Jupyter lab terminal

It happens on all terminals, continually. You type and all of sudden nothing comes out for a few seconds, then it's okay for a few seconds, then it freezes again.

Standard_E4ds_v5

This happens on old and fresh ML compute.

The only consistency seems to be US East 2, we have multiple workspaces there, and they all exhibit the problem. workspaces in other regions are all much smoother
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-06-09T18:41:23.85+00:00

Thanks for the detailed information, this is very helpful.

From what you’ve described, this pattern does not look like a typical compute sizing or workload issue, especially since:

It happens on a freshly booted instance

Only a Jupyter terminal is running

It is consistent across multiple workspaces

And is limited to the US East 2 region

This strongly points toward a regional or infrastructure-level issue rather than something specific to your compute instance or configuration.

A few things to consider:

Region-specific behavior Since the issue is reproducible across multiple workspaces in US East 2 but not in other regions, this suggests there may be latency, backend load, or networking issues affecting that region’s Azure ML compute infrastructure.

Jupyter terminal lag pattern. The behavior you described (input freezing for a few seconds, then catching up) is often seen when there is:

Intermittent network latency between browser and compute

Or backend I/O throttling / control plane delays

Not related to VM size Using Standard_E4ds_v5 should be sufficient for terminal usage, and since the problem occurs even when idle, it’s unlikely to be CPU or memory pressure.

What you can try as a workaround:

Test the same setup in another nearby region (for example: East US or Central US) to confirm the difference

Try connecting via a different network (to rule out client-side latency)

If possible, open browser developer tools and observe if there are delayed WebSocket responses when the freeze happens

At this point, based on your observations, this appears to be a region-specific service degradation rather than expected behavior.

Please continue monitoring, and if you notice any pattern changes (time-based spikes, specific hours, etc.), sharing that detail would help narrow it down further.

Thank you!
Mathieu Longtin 116 Reputation points Microsoft Employee

2026-06-10T13:30:44.0166667+00:00

I'm already using other regions as well, this behavior is not in other regions, as noted in my previous message. I have to use US East 2 as well, I can't not use it. So can you investigate this properly instead of feeding my answers to an AI so it repeats what I said?
Anshika Varshney 15,625 Reputation points Microsoft External Staff Moderator

2026-07-07T18:24:29.2766667+00:00

Hello @Mathieu Longtin

Please let me know if the issue persists after these checks. If you have any remaining questions or need additional details, I’ll be glad to provide further clarification or guidance.

Thankyou!
Manish Deshpande 8,055 Reputation points Microsoft External Staff Moderator

2026-07-16T00:49:08.9233333+00:00

Hello Mathieu
I just wanted to kindly follow up to check if you had a chance to review my earlier response. I hope the information shared was helpful. Please feel free to reach out if you have any additional questions or need further clarification.
Manish Deshpande 8,055 Reputation points Microsoft External Staff Moderator

2026-07-22T22:36:19.6066667+00:00

Hello Mathieu
I just wanted to kindly follow up to check if you had a chance to review my earlier response. I hope the information shared was helpful. Please feel free to reach out if you have any additional questions or need further clarification.

Answer 1

Mathieu Longtin 116 Microsoft Employee

Issue is still persisting

0 comments