We have a deployment slot that we deploy to, which we then warm up, and then swap with the live slot so that we can achieve zero downtime deployment on PaaS. This works very well in general.

However, we are noticing an issue where both of the slots appear to be responding to the event queue and processing things like item:saved events and updating the indexes and weird things are happening like duplicate documents ending up in the index.

Currently, it seems like the best option is to be very diligent about stopping the staging slot and then rebuilding the indexes once the staging slot is turned off.

Has anyone dealt with this issue before?

  • It is very hard to do zero downtime for CM. Content freeze is still required to get around this problem. Have a look at this blog post robhabraken.nl/index.php/2683/the-staging-slot-eventqueue-issue Commented Nov 12, 2019 at 19:04
  • 1
    My general recommendation is to not keep the CM staging slot running long enough to have this problem. i.e. deploy and swap the slot and then stop the old one as soon as possible. It seems to work fine for all the installs I've done. Commented Nov 12, 2019 at 22:56

1 Answer 1


The manual approach is to add a patch file for disabling events / indexing on the slotted App Service and to disable it once the slot is swapped into production (which is what is suggested in the article that was mentioned in the comments).

Another idea to prevent the secondary (non-production) slot from processing events and updating indexes would be to leverage environment variables and App settings alongside Sitecore configuration transforms.

Here is some crucial information about slots (source):

When you clone configuration from another deployment slot, the cloned configuration is editable. Some configuration elements follow the content across a swap (not slot specific), whereas other configuration elements stay in the same slot after a swap (slot specific). The following lists show the settings that change when you swap slots. Settings that are swapped:

  • General settings, such as framework version, 32/64-bit, web sockets
  • App settings (can be configured to stick to a slot)
  • Connection strings (can be configured to stick to a slot)
  • Handler mappings
  • Public certificates
  • WebJobs content
  • Hybrid connections *
  • Service endpoints *
  • Azure Content Delivery Network *
  • Path mappings

Something else to look into is the concept of configuration builders:

Lastly, here's a visual of the App settings blade to showcase some of the functionality:

app service settings blade

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.