Azure ML Compute Instance stuck in Creating state

Basalay, Maryna 0 Reputation points
2026-10-19T00:09:20.8133333+00:00

I am using an Azure for Students subscription and an Azure Machine Learning workspace in North Central US. I am unable to successfully provision a Compute Instance.

My current Compute Instance (Standard_DS11_v2) has remained in the Creating state for over two hours. I previously tried several other VM sizes (Standard_F4s_v2, Standard_D2as_v4, and Standard_E4ds_v4) with similar results.

I have confirmed that sufficient vCPU quota is available, the required resource providers are registered, there are no resource locks, and public network access is enabled. Azure ML diagnostics and Azure Service Health report no issues. The Activity Log shows that the compute creation request was accepted, but provisioning never completes.

Has anyone experienced this issue with Azure ML Compute Instances in North Central US? Is there anything else I can check, or could this indicate a backend provisioning/capacity issue?

Azure Machine Learning
0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-10-19T00:10:21.56+00:00

    The strongest next test is to create a temporary Azure Machine Learning workspace in another region and provision a small CPU Compute Instance there, because a Compute Instance cannot be placed in a region different from its workspace and available quota does not guarantee North Central US capacity.^1^

    Is this likely a capacity issue?

    It is plausible, but the current evidence does not prove it:

    • Compute Instance creation normally takes approximately five minutes, so more than two hours is abnormal.
    • Azure explicitly defines quota as a credit limit, not a capacity guarantee. Allocation can still fail when the selected region lacks capacity for a SKU.^1^
    • Trying several VM families reduces the likelihood of a single-SKU shortage, but it does not eliminate a regional allocation or Azure ML backend issue.
    • The public Azure status page does not show a widespread Azure Machine Learning incident specific to North Central US. That page covers widespread incidents; subscription- or region-specific events may appear only in Service Health.^2^

    Since you already checked family quota, providers, locks, public networking, diagnostics, Service Health, and multiple SKUs, do not repeat those checks.

    Run these remaining discriminating tests

    1. Check the separate Azure ML total-compute limit In Azure portal → Quotas, filter for Azure Machine Learning in North Central US and inspect both:
      • Dedicated cores for the relevant VM family.
      • Total compute limit per region.
      The total-compute limit is separate from core quota and is shared by training clusters, Compute Instances, and managed online endpoint deployments. A Compute Instance counts as one compute resource.^3^
    2. Check the workspace’s default storage prerequisite Open the workspace in the Azure portal, locate its default storage account, and go to: Storage account → Configuration → Allow storage account key access This setting must be enabled for Compute Instance creation. Also inspect the storage account’s Activity Log at the original creation time for denied key or storage operations.^1^ This is still relevant even with public network access enabled; public access and storage-account key access are separate settings.
    3. Perform a region-isolation test A Compute Instance must be in its workspace’s region; unlike a compute cluster, it cannot be created in a different region from that workspace.^4^ Therefore:
      1. Create a temporary workspace in another region available to the Azure for Students subscription.
      2. Keep the workspace configuration standard—no VNet, private endpoints, setup scripts, or custom applications.
      3. Create a small supported CPU Compute Instance.
      4. Interpret the result:
        • Succeeds: strongly isolates the issue to North Central US allocation or the original workspace.
        • Also hangs: points toward a subscription-level policy/backend issue or a shared workspace dependency rather than one regional SKU.
      If only training compute is required, a Compute Cluster can alternatively be created in another region, although this can add latency and data-transfer costs.^4^

    Escalate the stuck operation

    If the storage prerequisite and total-compute limit are valid and the cross-region test succeeds, this needs Microsoft to inspect backend provisioning traces.

    1. Open Resource group → Activity log.
    2. Select the accepted Compute Instance creation operation.
    3. Open JSON and save:
      • Correlation ID
      • Operation ID
      • Timestamp in UTC
      • Workspace and Compute Instance resource IDs
      • Requested SKU and region
    4. Capture the Compute Instance resource’s current provisioning state.
    5. Open an Azure support request under Azure Machine Learning → Compute Instance → Start, Stop or Restart Compute Instance and include the above data plus the list of SKUs already tested.

    A comparable accepted case required backend investigation/retry after quota had already been ruled out; its guidance likewise recommends supplying the correlation ID when the Activity Log contains no actionable error.^5^

    After collecting the operation details, delete the unusable stuck instance before further retries to avoid leaving an orphaned resource or possible charges.


    References

    1. Create a compute instance - Azure Machine Learning
    2. Azure status
    3. Manage resources and quotas - Azure Machine Learning
    4. Create an Azure Machine Learning compute cluster
    5. Azure ML Provisioning Error - An internal server error occurred. If the problem persists, contact support. - Microsoft Q&A
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.