Azure Document Intelligence stuck in Accepted: F0 to S0 upgrade fails with RequestConflict

Do not run another SKU update while the account remains Accepted; identify the original control-plane operation from the Activity Log, and if it has remained non-terminal since September, request Microsoft to clear or complete that operation without recreating the resource.

Accepted means Azure Resource Manager still considers an asynchronous create/update/delete operation active. Only Succeeded, Failed, or Canceled are terminal states, so subsequent writes can legitimately return HTTP 409 RequestConflict.^1^

1. Capture the resource state and relevant operations

First, query the current state without modifying the resource:

RESOURCE_ID="/subscriptions/[Subscription ID] ID]/resourceGroups/[Resource Group] Group]/providers/Microsoft.CognitiveServices/accounts/<name>"

az resource show --ids "$RESOURCE_ID" \
  --query "{state:properties.provisioningState,sku:sku.name,location:location}" \
  --output json

Then retrieve all activity for the resource, not only failed entries:

az monitor activity-log list \
  --resource-id "$RESOURCE_ID" \
  --start-time "2026-09-01T00:00:00Z" \
  --end-time "2026-11-13T00:00:00Z" \
  --max-events 1000 \
  --select eventTimestamp operationName status subStatus caller \
           correlationId operationId properties \
  --output json > document-intelligence-activity.json

The CLI supports filtering by resource ID, time range, status, operation ID, and correlation ID.^2^ Activity Log data is retained for up to 90 days, so export the September entries now before they age out.

Inspect the export for:

• A Started or Accepted write without a matching terminal event.
• Events sharing the same correlationId or operationId.
• The caller that initiated the operation.
• properties.statusMessage, subStatus, and any nested error.
• Policy, authorization, identity, networking, or dependency errors.

For each relevant correlation ID, export its complete event set:

az monitor activity-log list \
  --correlation-id "<correlation-id>" \
  --start-time "2026-09-01T00:00:00Z" \
  --query "[].{time:eventTimestamp,operation:operationName.value,status:status.value,subStatus:subStatus.value,error:properties.statusMessage}" \
  --output json > correlation-diagnostics.json

A correlation ID groups events belonging to the same broader ARM action; it is the appropriate identifier to provide to support.^3^

2. Determine whether the operation can still be tracked

If the original September response was captured by automation, deployment logs, a browser trace, or an HTTP client, look for:

• Azure-AsyncOperation
• Location
• Retry-After

Poll the exact URL from Azure-AsyncOperation; use Location only if the former was not returned. Tracking may require resource-group-level permission because operation-status URLs are not necessarily scoped to the resource.^1^

Do not reconstruct or guess the operation-status URL. If the response headers were not retained and the Activity Log exposes no status URL, there is no documented client-side command in the supplied evidence to cancel or clear this Cognitive Services operation.

The proposed CLI SKU update is still another write against the same account. Because the portal write already fails on the non-terminal state, it is not a distinct recovery mechanism.

3. Use Resource Health for no-plan escalation

Open:

Azure portal → Document Intelligence resource → Resource health

Also check:

Azure portal → Service Health → Health history, filtered to Azure AI services and Brazil South. Service Health is subscription- and region-specific, unlike the broad public status page.^4^

If Resource Health reports Unavailable due to a platform event, select the support option from that pane. Microsoft documents that a support agreement is not required to open a request when Resource Health marks the resource unavailable because of a platform event.^5^

Request this explicitly:

Preserve the existing Microsoft.CognitiveServices account, endpoint, keys, and resource ID. Investigate the non-terminal provisioning operation and complete, fail, cancel, or clear it server-side. Do not delete, purge, or recreate the account. After the state becomes terminal, retry the F0-to-S0 SKU update.

Attach:

• Resource ID and region.
• Current provisioningState and SKU output.
• Exact UTC timestamps.
• September and November correlation/operation IDs.
• Activity Log JSON exports.
• The full RequestConflict response.
• Resource Health and Service Health results.

Similar Cognitive Services cases have required product-group backend cleanup when ARM-visible writes could not clear the non-terminal state.[^6^](https://learn.microsoft.com/answers/a/12959890 "Azure AI Services: account stuck in non-terminal "Accepted" provisioning state after its CMK key vault and managed identity were deleted — delete fails with RequestConflict, needs backend clear - Microsoft Q&A")

If Resource Health does not provide platform-event support, this remains a technical support case, for which Microsoft documents that a support plan is required. Ticket creation also requires subscription-level Owner, Contributor, Support Request Contributor, or equivalent Microsoft.Support/* permission.^7^ With Basic support, the remaining public escalation route is Microsoft Q&A/Azure Support community escalation; post only timestamps, region, state, and error text publicly, and provide identifiers privately when a moderator establishes an official channel.

References

1. Track asynchronous Azure operations
2. az monitor activity-log list
3. Get operation correlation ID from Activity Log for Microsoft Discovery
4. Azure Service Health FAQ
5. Azure Resource Health FAQ
6. Azure AI Services: account stuck in non-terminal "Accepted" provisioning state after its CMK key vault and managed identity were deleted — delete fails with RequestConflict, needs backend clear - Microsoft Q&A
7. Create an Azure support request