Forum Discussion
Microsoft Fabric ML Model Endpoint remains "Activating" indefinitely after activation request
Hi,
I'm using Microsoft Fabric ML Model Endpoints as part of an automated DEV → UAT promotion pipeline.
Scenario
The pipeline performs the following steps:
- Download model artifacts
- Validate SHA256
- Register model versions in UAT
- Create/register UAT model versions successfully
- Activate the matching UAT model endpoint version
Registration completes successfully.
e.g result
{
"endpoint_http_status": 202,
"endpoint_action_requested": true
}
Problem
POST /activate
→ HTTP 202 Accepted
``
the endpoint remins in
Activating state forever
Questions
- Is there a known issue where Fabric ML Model Endpoints can remain in Activating indefinitely after a successful activation request?
- Is there a recommended maximum time for an endpoint to remain in Activating before it should be considered failed?
- Is there a supported way to determine why endpoint provisioning is stuck?
- Should an endpoint that remains in Activating be:
- left alone,
- deactivated and reactivated,
- or recreated entirely?
- Are there diagnostic logs available for endpoint provisioning failures?
Any guidance from the Fabric product team or community would be greatly appreciated.
Thank you.
5 Replies
- DreamITLearn
Advocate II
Hi fabric_user16,
a 202 only means the activation request was accepted, not that provisioning succeeded.- Known issue / max time: I couldn’t find a documented maximum or a known “stuck forever” issue. Microsoft’s docs say Fabric sets up the container infrastructure in the background and the endpoint should go active within a few minutes. In an automated pipeline, I’d treat anything past roughly 10 to 15 minutes as failed. That threshold is my own suggestion, not an official limit.
- Finding the cause: Poll GET /v1/workspaces/{workspaceId}/mlmodels/{modelId}/endpoint and read the version status. It returns Activating, Deactivating, Running, or Failed, and the docs show an example of an activation failure response.
- What to do with a stuck endpoint: Don’t wait indefinitely. Deactivate it, wait for it to settle, then reactivate. If it sticks again, re-register the model version and activate the new one. As a last resort, open a support ticket with the workspace ID, model ID, version name, and the request/activity IDs from the API response.
- Diagnostic logs: I couldn’t find a dedicated provisioning log for endpoints. The status and error details in the API response, plus a support ticket, are the main routes.
Checks worth doing first:
- The ML endpoints tenant setting is enabled in the Admin portal.
- The capacity isn’t a free or trial SKU, and isn’t paused or throttled.
- The model flavor supports endpoints. In one community thread, a Spark model saved through MLflow failed to activate for this reason.
- The artifacts you promoted from DEV are complete, including dependencies and environment files, and the model has a valid MLflow signature.
- fabric_user16New Member
Thanks for the suggestions. We investigated further and found a few additional details:
The models register successfully and endpoint activation requests return 202 Accepted, so the request itself is being accepted.
The models have valid MLflow signatures and are sklearn-based.
Using the Fabric API, we checked the endpoint status and found that all versions remain in Activating for more than 20 hours and never transition to Active or Failed.
The Service Principal receives a valid Fabric token
Our deployment logs show:
- endpoint_status: ActivationBlockedByServicePrincipalOBO
- endpoint_reason: SERVICE_PRINCIPAL_OBO_NOT_SUPPORTED
Manual activation from the Fabric UI appears to work, while activation via Azure DevOps using a Service Principal does not.
Has anyone successfully activated Fabric ML model endpoints using Service Principal authentication via the REST API? We're trying to determine whether this is a known limitation of endpoint activation with SPNs or a backend provisioning issue causing the endpoints to remain permanently in the Activating state.
- Prince0011
Memorable Member
Hi,
I haven’t seen an official max time for Activating, so I’d treat anything past 10-15 minutes as stuck. It’s still in preview, so I can’t point to a known issue.
A 202 only means the request was accepted. Poll GET /v1/workspaces/{workspaceId}/mlmodels/{modelId}/endpoint, since it can show a Failed state with a reason. Also check the UAT capacity isn’t paused or throttled.
If it’s stuck, deactivate and reactivate first, then recreate only if that fails. Add a timeout in the pipeline.
If this helped, feel free to give it a kudos or mark it as solution, helps others find it too.
- fabric_user16New Member
Hi,
Thank you for your help.
We have observed that the model activates successfully when activation is performed manually in UAT using a user account. However, when activation is triggered through our Azure DevOps pipeline using a Service Principal (SPN), the model remains in the Activating state indefinitely.
As the activation request is initiated by the pipeline, we are unable to perform a deactivate/reactivate cycle while it is still stuck in the Activating state.
We have not yet investigated the endpoint status via the GET API or checked the UAT capacity for throttling. Could you please advise where we can view the endpoint status details, failure reasons, and any capacity-related diagnostics within Fabric?
During your testing, were activation scenarios validated through automated pipelines using a Service Principal, or only through the Fabric UI using a user account? We are trying to determine whether the issue may be specific to SPN-based activation.
Thank you!
- v-abhinavmu
Community Support
Hi fabric_user16,
Thank you for sharing the additional details.Since activation succeeds through the Fabric UI but remains in Activating when triggered through Azure DevOps using a Service Principal, I recommend checking both the long-running operation status and the specific model version status.
1. Check the activation operation: The activation API returns 202 Accepted when activation is in progress. Capture the x-ms-operation-id from the response and call GET /v1/operations/{operationId} to check whether the operation is Running, Succeeded, or Failed. Follow the Retry-After header when polling.
2. Check the model endpoint version: Call GET /v1/workspaces/{workspaceId}/mlmodels/{modelId}/endpoint/versions/{name} and review the status. If the status is Failed, inspect failureDetails for the error code and message.
3. Investigate the Service Principal-specific error: Your deployment logs report ActivationBlockedByServicePrincipalOBO and SERVICE_PRINCIPAL_OBO_NOT_SUPPORTED. The activation API documentation lists Service Principals and Managed Identities as supported identities. However, this does not establish the cause of the reported error, so further investigation is needed.
Since the endpoint has remained in Activating for more than 20 hours, if these checks do not identify the cause, I recommend contacting Microsoft Support for further investigation. Include the operation ID, request ID, workspace ID, model ID, model version, and relevant deployment logs.
For more details, please refer to the below Official Microsoft documentation:
• Endpoint - Activate ML Model Endpoint Version - REST API (MLModel) | Microsoft Learn
• Long Running Operations - Get Operation State - REST API (Core) | Microsoft Learn
• Endpoint - Get ML Model Endpoint Version - REST API (MLModel) | Microsoft Learn
• Serve real-time predictions with ML model endpoints (Preview) - Microsoft Fabric | Microsoft Learn
• Create a Fabric and Power BI Support Ticket - Power BI | Microsoft LearnI hope this helps. Please feel free to reach out if you have any further questions.
Thank you.