ResourceModified
Azure ResourceModified means a write targeted resource state that changed after the caller read it, so the stale mutation was rejected.
Last reviewed: April 27, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Resource Modified Mean?
Azure protected the resource from a stale update. A client read a version, another actor advanced that version, and the later mutation tried to apply changes against the old baseline. The useful boundary is optimistic concurrency: ETag/version source, concurrent writer timeline, retry behavior, and whether the update can be safely rebased.
Common Causes
- -Update request includes an outdated ETag, version token, or baseline resource snapshot from a previous read.
- -Another deployment, remediation job, portal edit, SDK client, or policy process modified the resource between read and write.
- -Queue workers retry old mutation messages after the live resource already advanced.
- -Tag, policy, lock, or identity automation patches the same resource fields from parallel pipelines.
- -Client cache or API gateway serves stale resource metadata to writers.
How to Fix Resource Modified
- 1Fetch the latest resource state and compare live ETag/version against the token used by the failed request.
- 2Rebase the intended patch on the current resource representation before retrying.
- 3Serialize or partition writes for hot resources such as shared tags, policy assignments, and manifests.
- 4Drop queued mutations whose baseline version is older than the live resource unless they can be recomputed safely.
- 5Avoid blind retries that reuse the same stale token or stale patch body.
Step-by-Step Diagnosis for Resource Modified
- 1Capture resource ID, operation, failed ETag/version token, request ID, caller, and mutation payload.
- 2Compare the failed token with the live token from a fresh resource read.
- 3Trace Activity Log and deployment operations for all writers touching the same resource during the failure window.
- 4Review retry code and queue payloads to confirm each attempt refreshes state before mutation.
- 5Replay the update path with single-writer control to prove whether contention or stale replay is the source.
Seen in Production
- -A tag normalizer and Terraform pipeline patch the same resource tags within seconds, and the second writer loses its original ETag.
- -A delayed queue worker retries an old update message after the resource was already modified by a portal hotfix.
- -A policy remediation task changes a managed identity property while a deployment script tries to update the same resource.
- -An API layer caches resource metadata and supplies stale ETags to multiple writer clients.
Version Token Drift Analysis
- -Compare submitted ETag/version against live value at failure time.
- -Check token lifecycle in client caches, queues, SDK wrappers, and API gateways.
Writer Contention and Retry Semantics
- -Inspect concurrent automation jobs for shared target mutations.
- -Validate retry flow refreshes state per attempt instead of resubmitting identical payload and token.
Decision Shortcut: Rebase vs Drop
- -If the intended mutation is still valid on the current resource, rebase it and retry with a fresh token.
- -If live state already includes the intended outcome, mark the job idempotently complete.
- -If live state advanced beyond the queued intent baseline, discard or regenerate the job rather than replaying stale state.
Wrong Fix to Avoid
- -Do not remove concurrency tokens or switch to last-writer-wins unless overwrites are explicitly acceptable.
- -Do not retry the same stale ETag/version and payload after ResourceModified.
- -Do not treat ResourceModified as Azure availability failure; it is a deterministic concurrency signal.
Implementation Examples
2026-04-27T10:16:42Z resource=/subscriptions/123/resourceGroups/prod/providers/Microsoft.Storage/storageAccounts/mediaeast
submittedEtag="W/\"datetime'2026-04-27T10%3A12%3A09.100Z'\"" liveEtag="W/\"datetime'2026-04-27T10%3A15%3A31.420Z'\""
status=412 error=ResourceModified writer=tag-normalizeraz monitor activity-log list \
--resource-id "$RESOURCE_ID" \
--start-time 2026-04-27T10:00:00Z \
--query '[].{time:eventTimestamp,caller:caller,operation:operationName.value,status:status.value}'const latest = await readResource(resourceId);
if (job.baselineEtag !== latest.etag) {
const patch = rebasePatch(job.intent, latest.body);
await updateResource(resourceId, patch, { ifMatch: latest.etag });
}Incident Timeline
10:12 UTC
A writer reads resource state and stores a version token
Signal: Job payload, SDK cache, or API response captures an ETag/version baseline for a later mutation.
Why it matters: That token is only safe until another writer changes the resource.
10:15 UTC
Another actor modifies the resource first
Signal: Activity Log shows portal edit, deployment, policy remediation, or tag automation advancing the resource version.
Why it matters: The queued or delayed mutation is now stale.
10:16 UTC
Azure rejects the stale mutation with ResourceModified
Signal: The write path fails because the submitted version token no longer matches live resource state.
Why it matters: Refresh and rebase are required before retry.
10:23 UTC
The mutation is rebased or discarded
Signal: The writer reloads current state, recomputes the patch, or marks the intent obsolete.
Why it matters: That confirms the failure lived in optimistic concurrency, not service health.
Seen in Production
Two automation jobs patch the same resource tags concurrently
Frequency: common
Example: Second patch fails because first patch already advanced resource version.
Fix: Serialize tag updates and refresh version token before each patch attempt.
Queue worker retries stale update message after long delay
Frequency: rare
Example: Deferred retry reuses old ETag and triggers ResourceModified repeatedly.
Fix: Refresh resource state at retry time and rebuild patch from latest baseline.
Policy remediation collides with deployment pipeline
Frequency: medium
Example: Policy updates tags while deployment script patches the same resource metadata.
Fix: Serialize writes by resource ID or route shared tag updates through one owner.
Wrong Fix vs Better Fix
Blind retry vs refresh and rebase
Wrong fix: Replay the same request body and ETag after ResourceModified.
Better fix: Read current state, rebase the intended change, and retry with a fresh token.
Why this is better: The stale token will keep failing until the request baseline changes.
Remove token vs coordinate writers
Wrong fix: Disable conditional updates to stop conflicts.
Better fix: Partition writes, serialize hot resources, or use a per-resource work queue.
Why this is better: Concurrency tokens prevent accidental overwrite of newer state.
Process stale queue vs validate baseline
Wrong fix: Execute delayed queue mutations exactly as originally serialized.
Better fix: Store intent plus baseline version and reject jobs whose baseline is no longer valid.
Why this is better: Old jobs often encode obsolete assumptions about live resource state.
Debugging Tools
- -ETag/version token comparison logs
- -Activity Log write timeline
- -Distributed tracing for concurrent writers
- -Retry behavior instrumentation
How to Verify the Fix
- -Rerun the write path and confirm rebased updates succeed without ResourceModified loops.
- -Validate post-write resource state matches expected final values under concurrent load.
- -Run stale-token tests and confirm old queued mutations are dropped or recomputed safely.
- -Observe reduced concurrency-conflict error rate in operation telemetry and Activity Log correlation.
How to Prevent Recurrence
- -Implement consistent optimistic concurrency utilities across all resource writers.
- -Use per-resource locking or queue partitioning for high-contention update paths.
- -Store mutation intent separately from the version baseline so stale jobs can be rebased rather than replayed.
- -Emit conflict metrics by resource type, writer identity, target field, and retry attempt.
Pro Tip
- -attach mutation intent version to job payloads and discard queued writes if the live resource version advanced past the intent baseline.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.