ResourceModified
Azure returns `ResourceModified` when a conditional update targets a stale resource version that changed after it was read.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
What Does Resource Modified Mean?
Concurrency safeguards blocked the mutation, preventing stale writes from overwriting newer state produced by another operation.
Common Causes
- -Update request includes outdated ETag or version token from a previous read.
- -Another actor modified the resource between read and write phases.
- -Conditional headers or concurrency tokens are cached beyond safe freshness window.
- -Parallel automation pipelines mutate the same resource without lock coordination.
How to Fix Resource Modified
- 1Fetch latest resource state and regenerate conditional tokens before retrying.
- 2Apply optimistic-concurrency pattern with read-refresh-write on every retry attempt.
- 3Serialize writes for hot resources to eliminate non-deterministic collisions.
- 4Avoid blind retries that reuse stale tokens.
Step-by-Step Diagnosis for Resource Modified
- 1Capture request token values (ETag/version) and compare against current server values.
- 2Trace concurrent write actors touching the same resource within failure window.
- 3Review retry logic to ensure each attempt refreshes state before mutation.
- 4Replay update path with single-writer control to confirm collision source.
Version Token Drift Analysis
- -Compare submitted ETag/version against live value at failure time (example: worker submits stale token from queue message generated minutes earlier).
- -Check token lifecycle in client cache layers (example: API gateway caches resource metadata and serves outdated ETag to writers).
Writer Contention and Retry Semantics
- -Inspect concurrent automation jobs for shared target mutations (example: policy remediation job and deployment pipeline patch same resource tags simultaneously).
- -Validate retry flow refreshes state per attempt (example: retry loop resubmits identical payload+token and repeatedly fails).
How to Verify the Fix
- -Rerun the write path and confirm updates succeed without `ResourceModified` failures.
- -Validate post-write resource state matches expected final values under concurrent load.
- -Observe reduced concurrency-conflict error rate in operation telemetry.
How to Prevent Recurrence
- -Implement consistent optimistic concurrency utilities across all writers.
- -Use per-resource locking or queue partitioning for high-contention update paths.
- -Emit conflict metrics and alert on sustained retry-collision loops.
Pro Tip
- -attach mutation intent version to job payloads and discard queued writes if the live resource version already advanced past the intent baseline.
Decision Support
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
404 Not Found vs 410 Gone: Missing vs Permanent Removal
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.
Playbook
Resource State Playbook (404 / 410 / ResourceNotFound)
Use this playbook to separate temporary missing-resource lookups from permanent removals, then fix scope, lifecycle, and identifier drift safely.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.