Users intermittently encounter "Page Not Found" (404) errors when navigating the website. The behavior is inconsistent — the same URL sometimes loads successfully and sometimes displays a 404 page. Application Insights logs show Progress.Sitefinity.RestSdk.Exceptions.ErrorCodeException exceptions.

The issue is typically observed only in production or under load, not in low-traffic staging environments. The 404 errors correlate with ErrorCodeException entries in Application Insights or error logs.

The intermittent 404 errors are caused by unhandled ErrorCodeException exceptions thrown by the Sitefinity REST SDK in custom Razor views, helpers, or layout files. When the CMS backend experiences a transient delay (e.g., brief timeout, rate limiting, or network hiccup), the REST SDK call fails with an ErrorCodeException. If this exception is not caught in the custom code, it propagates up through the rendering pipeline, causes the entire page render to fail, and surfaces to the end-user as a 404 error.

Common contributing factors include:

• No try-catch error handling around REST SDK calls in custom Razor views, helpers, or layout files.
• No caching of REST SDK data — every page render makes multiple live REST API calls to the CMS, any one of which can fail.
• REST SDK calls placed in shared layout views (e.g., _Layout.cshtml, Default.cshtml), meaning every page on the site is affected.
• Synchronous blocking patterns (.Result or .GetAwaiter().GetResult()) on async REST SDK calls, which can cause thread pool starvation under production-level traffic.
• N+1 query patterns — making individual REST SDK calls in a loop instead of batching.

1. Add try-catch error handling around all REST SDK calls in custom code, especially in shared layout views and helpers. Return graceful fallback content instead of letting exceptions crash the page render:
   
   

   try
   {
       var newsItems = await restClient.GetItems<NewsItem>(new GetAllArgs());
       // process news items
   }
   catch (ErrorCodeException ex)
   {
       // Log the error and return fallback/default content
       logger.LogWarning(ex, "REST SDK call failed, using fallback.");
   }

    

2. Implement caching for REST SDK data that rarely changes (e.g., taxonomy items, navigation data, site settings). Use IMemoryCache or IDistributedCache to avoid making live REST calls on every page render:
   
   

   var cacheKey = "LatestNewsItems";
   if (!cache.TryGetValue(cacheKey, out List<NewsItem> newsItems))
   {
       newsItems = await restClient.GetItems<NewsItem>(new GetAllArgs());
       cache.Set(cacheKey, newsItems, TimeSpan.FromMinutes(10));
   }

    

3. Convert synchronous blocking calls (.Result, .GetAwaiter().GetResult()) to proper async/await patterns to prevent thread pool starvation.
4. Eliminate N+1 query patterns by fetching data in batch instead of making individual REST SDK calls in a loop.
5. Move hardcoded credentials (ClientId, ClientSecret, Username, Password) out of source code and into secure configuration sources such as environment variables or Azure Key Vault.

• Use Sitefinity ASP.NET Core Renderer page diagnostics (?sfdiagnostics query parameter) to identify the number and duration of REST SDK calls per page render.
• Monitor Application Insights for ErrorCodeException occurrences to measure the frequency of transient failures before and after applying fixes.