I am using our own Sitecore Error Manager in a Sitecore 8.2 project. If an item is not found or an error occurs, our error page is called within the current client request. This error handler calls a configured Error content page within Sitecore.

Since the introduction of the xDB, a call to this page takes > 10 seconds before the internal request finishes. This happens, because we forward all client cookies to this call, including the Analytics cookie.

At the end of this pageload, we see the following in the logfile:

Overriding expired contact session lock for contact id: 41a8f96f-7aa8-413e-9731-eecbb414bd24

This happens because the user currently has an open request. The nested request runs into the session lock which eventually get released.

Question: Is it possible to disable the Tracker for this nested request by request parameter or a cookie or something? It is not neccessary at all. Not forwarding the analytics cookie is my least favorited solution since the request would be tracked with a new visitor session, which fills the contacts with garbage data.

I tried to stop the tracking in the Analytics settings of the nested page itself but had no luck with this. The problem still appears.

2 Answers 2


There are a few options that may work for you:

Disable the tracker in code behind

Set Tracker.Enable to false in the pre-initialization stage of your page:

protected override void OnPreInit(EventArgs e)
    Sitecore.Analytics.Tracker.Enabled = false;

Disable tracking for the page item

If your error page is represented by a Sitecore item, you can do the following:

  • Open the Content Editor;
  • Select your error page item in the content tree;
  • Click the button "Attributes" in the ribbon "Analyze";
  • Go to the "Settings" tab;
  • Check the checkbox "Disable analytics for this page";
  • Publish.

Disable tracking on the <site> definition

Put your error page into a separate site and set the enableTracking attribute to false on the site definition.

Disable tracking in a custom <startAnalytics> processor

xDB uses the startAnalytics pipeline to check whether or not it should be active in the current request. You can add your own processor to this pipeline:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
          type="Your.Custom.Processor, Your.Assembly"
          patch:after="processor[@type='Sitecore.Analytics.Pipelines.StartAnalytics.CheckPreconditions, Sitecore.Analytics']" />

In your custom processor, you'll need to set Tracker.Enabled to false based on some condition. For example, you can do it if a certain cookie is present or if a custom query string parameter takes a specific value.

  • Hi Dmytro. Method 1 is probably the way to go, but i have to think about where to place something like this in a MVC solution. But probably this will not work because the lock is burried deeper in the whole thing. Method 2 is what i already tried and method 3 is no solution because it is really just for specific requests and not for whole sites (which would fix the issue). Commented Oct 17, 2016 at 12:44
  • 1
    @PascalMathys How about Method 4? Commented Oct 17, 2016 at 12:55
  • 1
    The approach in Method 4 is the way to go! I will integrate such a processor into the Error Manager module so that only the Error Manager requests are able to force disable the tracker. Thanks for your help! Commented Oct 17, 2016 at 13:20

I use Tracker.Current.CurrentPage.Cancel(); in code for things like Ajax requests to tell Sitecore to cancel the current request. It might help here as well.

  • 2
    The problem with this approach is that the xDB pipelines will be executed before your code. For example, tracker initialization and contact locking logic will still be used, which is what the OP is trying to prevent. Commented Oct 17, 2016 at 12:37
  • I found that I needed to do both this and the accepted answer to get my pages not to show up in analytics. Simply setting Tracker.Enabled to false still allowed the whole interaction to be saved to mongodb. Commented May 11, 2017 at 18:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.