Azure Front Door Standard: UrlRewrite action inconsistently rewrites the same URL (identical config, result flips between 200 and 404)

I'm seeing a reproducible, inconsistent behavior in the UrlRewrite Rules Engine action on Azure Front Door Standard, using a configuration that matches the official documentation example exactly.

Context

• Front Door Standard (sku.name: Standard_AzureFrontDoor)
• Origin: Azure Storage Static Website (*.z##.web.core.windows.net)
• Goal: SPA fallback (React/Vite) — rewrite any client-side route (/login, /dashboard, etc.) to /index.html before it reaches the origin, since the Storage account has no physical blob for those routes and its native 404 fallback always returns HTTP 404 even when serving the correct content.

Rule configuration (identical to the official doc example)

{
  "actions": [
    {
      "name": "UrlRewrite",
      "parameters": {
        "destination": "/index.html",
        "preserveUnmatchedPath": false,
        "sourcePattern": "/",
        "typeName": "DeliveryRuleUrlRewriteActionParameters"
      }
    }
  ],
  "conditions": [],
  "matchProcessingBehavior": "Continue",
  "order": 3
}

The associated route has patternsToMatch: ["/*"]. No condition is configured — this should apply to 100% of requests on that route.

Problem

The same rule, for the same URL (/login), flips between working (200, rewrite applied) and not working (404, original path reaches the origin untouched) over time, with zero configuration changes between attempts.

Evidence collected from the official Front Door Access Logs (Log Analytics, FrontDoorAccessLog), same rule, minutes apart:

18:24:29 | /login              | status=404 | origin=.../login              (NOT rewritten)
18:24:56 | /login              | status=404 | origin=.../login              (NOT rewritten)
18:25:23 | /login              | status=404 | origin=.../login              (NOT rewritten)
18:25:38 | /test-spa?cb=22826  | status=200 | origin=.../index.html?cb=22826 (rewritten OK)
18:25:42 | /login?cb=13127     | status=404 | origin=.../login?cb=13127     (NOT rewritten)

Later, the same /login URL started consistently returning 200 across several consecutive checks (~10 min), again with no configuration change — suggesting a propagation convergence much slower than the documented "up to 15 minutes," or some other edge-node instability.

What I've already tested/ruled out

• Not caching: random query string on every request.
• Not a syntax error: config is a direct copy of the official doc example (sourcePattern: "/", preserveUnmatchedPath: false).
• Not "normal" propagation delay: tested over 20-40 minutes on multiple occasions, well beyond the documented window.
• The rulesEngineMatchNames_s field in the access logs is always empty ([]), even on requests where the rewrite clearly happened (confirmed via originUrl_s changing to /index.html) — so this field isn't reliable for diagnosing whether a rule actually fired.
• deploymentStatus from the API always shows NotStarted even with provisioningState: Succeeded (I know this field is a known unreliable indicator — mentioning it only for context).

Questions for the community

1. Has anyone else observed this specific kind of instability (correct/incorrect result flipping over time, identical config, same URL) with UrlRewrite on Front Door Standard?
2. Is there a known difference in Rules Engine maturity/implementation between the Standard and Premium tiers that would explain this?
3. Is there any CLI/API way to confirm a rule change has actually propagated to all PoPs (without relying on deploymentStatus, which I know is unreliable)?
4. Does anyone still trust UrlRewrite as a SPA-fallback solution against a Storage Static Website origin, or has the practical recommendation shifted to something else (Azure Static Web Apps, a Function App as a thin proxy, etc.)?I'm seeing a reproducible, inconsistent behavior in the UrlRewrite Rules Engine action on Azure Front Door Standard, using a configuration that matches the official documentation example exactly.

   Context

   • Front Door Standard (sku.name: Standard_AzureFrontDoor)
     • Origin: Azure Storage Static Website (*.z##.web.core.windows.net)
       • Goal: SPA fallback (React/Vite) — rewrite any client-side route (/login, /dashboard, etc.) to /index.html before it reaches the origin, since the Storage account has no physical blob for those routes and its native 404 fallback always returns HTTP 404 even when serving the correct content.

   Rule configuration (identical to the official doc example)

      {
   

"actions": [ { "name": "UrlRewrite", "parameters": { "destination": "/index.html", "preserveUnmatchedPath": false, "sourcePattern": "/", "typeName": "DeliveryRuleUrlRewriteActionParameters" } } ], "conditions": [], "matchProcessingBehavior": "Continue", "order": 3 }

   
   The associated route has `patternsToMatch: ["/*"]`. No condition is configured — this should apply to 100% of requests on that route.
   
   ### Problem

   The same rule, for the same URL (`/login`), flips between working (200, rewrite applied) and not working (404, original path reaches the origin untouched) **over time, with zero configuration changes between attempts**.
   
   Evidence collected from the **official Front Door Access Logs** (Log Analytics, `FrontDoorAccessLog`), same rule, minutes apart:
   
   ```typescript
   18:24:29 | /login              | status=404 | origin=.../login              (NOT rewritten)
18:24:56 | /login              | status=404 | origin=.../login              (NOT rewritten)
18:25:23 | /login              | status=404 | origin=.../login              (NOT rewritten)
18:25:38 | /test-spa?cb=22826  | status=200 | origin=.../index.html?cb=22826 (rewritten OK)
18:25:42 | /login?cb=13127     | status=404 | origin=.../login?cb=13127     (NOT rewritten)

Later, the same /login URL started consistently returning 200 across several consecutive checks (~10 min), again with no configuration change — suggesting a propagation convergence much slower than the documented "up to 15 minutes," or some other edge-node instability.

What I've already tested/ruled out

  - Not caching: random query string on every request.
  
     - Not a syntax error: config is a direct copy of the official doc example (`sourcePattern: "/"`, `preserveUnmatchedPath: false`).
     
        - Not "normal" propagation delay: tested over 20-40 minutes on multiple occasions, well beyond the documented window.
        
           - The `rulesEngineMatchNames_s` field in the access logs is **always empty (`[]`)**, even on requests where the rewrite clearly happened (confirmed via `originUrl_s` changing to `/index.html`) — so this field isn't reliable for diagnosing whether a rule actually fired.
           
              - `deploymentStatus` from the API always shows `NotStarted` even with `provisioningState: Succeeded` (I know this field is a known unreliable indicator — mentioning it only for context).
              

Questions for the community

1. Has anyone else observed this specific kind of instability (correct/incorrect result flipping over time, identical config, same URL) with UrlRewrite on Front Door Standard?
2. Is there a known difference in Rules Engine maturity/implementation between the Standard and Premium tiers that would explain this?
3. Is there any CLI/API way to confirm a rule change has actually propagated to all PoPs (without relying on deploymentStatus, which I know is unreliable)?
4. Does anyone still trust UrlRewrite as a SPA-fallback solution against a Storage Static Website origin, or has the practical recommendation shifted to something else (Azure Static Web Apps, a Function App as a thin proxy, etc.)?