40 results found

1. Official guidance for HTTP QUERY method support in Optimizely DXP

   Summary

   The HTTP QUERY method (RFC 10008) provides a standardized way to perform safe, idempotent query operations while allowing a request body, addressing a long-standing limitation of GET.

   https://www.rfc-editor.org/info/rfc10008/

   https://tykok.medium.com/the-new-http-method-query-d1dc3efc35c4

   While ASP.NET Core applications can implement support for QUERY, developers deploying to Optimizely DXP also depend on the surrounding platform and infrastructure.

   Request

   Could Optimizely publish official guidance regarding support for the HTTP QUERY method in DXP?

   Specifically, it would be helpful to clarify:

   • Is QUERY currently supported throughout the DXP infrastructure?
   • If not, which components prevent support (Cloudflare, WAF, load balancers, Azure App Service, proxies, etc.)?
   • Are there any security considerations specific to QUERY that developers should be aware of?
   • Will QUERY be treated similarly to GET regarding safe/idempotent semantics where applicable?
   • Is support on the product roadmap, or is it considered out of scope?
   • If there is no current support, what is the recommended approach for developers who would otherwise benefit from QUERY?

   Why this matters

   Many APIs expose complex search and filtering operations that naturally fit a safe, idempotent request but exceed the practical limitations of GET query strings.

   The QUERY method provides a standards-based solution to this problem. As more frameworks begin supporting it, developers will naturally want to know whether Optimizely DXP fully supports the method before adopting it.

   Even if official support is not yet planned, having clear documentation describing the current state and any platform limitations would help developers make informed architectural decisions.

   Thank you for considering publishing official guidance.

   Summary

   The HTTP QUERY method (RFC 10008) provides a standardized way to perform safe, idempotent query operations while allowing a request body, addressing a long-standing limitation of GET.

   https://www.rfc-editor.org/info/rfc10008/

   https://tykok.medium.com/the-new-http-method-query-d1dc3efc35c4

   While ASP.NET Core applications can implement support for QUERY, developers deploying to Optimizely DXP also depend on the surrounding platform and infrastructure.

   Request

   Could Optimizely publish official guidance regarding support for the HTTP QUERY method in DXP?

   Specifically, it would be helpful to clarify:

   • Is QUERY currently supported throughout the DXP infrastructure?
   • If not, which components prevent support (Cloudflare, WAF, load balancers, Azure App Service, proxies, etc.)?
   • Are there any… more
   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  1 comment  ·  DXP, Hosting & Infrastructure  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. DXP support for apex domain

   Currently DXP only supports complete hostnames containing both the subdomain and apex domain e.g. www.mywebsite.com.

   We would like to request support for configuring the apex (root) domain (e.g. mywebsite.com) as the primary domain within DXP.

   Traffic can then be redirected from www.mywebsite.com to mywebsite.com.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Application Insights - be able to sample or filter logged data

   As a customer and implementation partner using DXP I would like either:

   • a built-in tool somewhere, in the DXP portal, optimizely or Azure, to be able to filter out unwanted third party dependencies from being logged to the DXP Application Insights,

   or

   • the permissions to add our own sampling in Application Insights.

   Optimizely DXP injects Application Insights (via required headers) and we cannot opt out of that. We don't have any way to sample the data logged to that Application Insights instance.

   We get alerts about "DXC - Production Application Insight Daily cap reached" on logged data that is mainly third party dependencies injected from marketing tools that we have no control over.
   There is no documentation or best practices at Optimizely on how to implement custom filtering of these.

   We have implemented a custom browserside filter in Optimizely where we can filter out the logging if unwanted third party dependencies. And we need to look up such unwanted dependencies ourselves in App Insights at regular intervals.
   This works well, the number of logged dependencies are now much lower.

   However, it would give us a much better experience and value from the product if it was not forced upon every customer to implement their own filter.

   As a customer and implementation partner using DXP I would like either:

   • a built-in tool somewhere, in the DXP portal, optimizely or Azure, to be able to filter out unwanted third party dependencies from being logged to the DXP Application Insights,

   or

   • the permissions to add our own sampling in Application Insights.

   Optimizely DXP injects Application Insights (via required headers) and we cannot opt out of that. We don't have any way to sample the data logged to that Application Insights instance.

   We get alerts about "DXC - Production Application Insight Daily cap reached" on logged data that is mainly… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. API support for environment copy-back lifecycle and post-copy script execution

   As a development team managing multiple lower environments, we want API/PowerShell endpoints to orchestrate the full copy-back workflow, including a mechanism to run registered post-copy maintenance scripts, so that I can automate environment refresh end-to-end without manual PaaS Portal interaction.

   Currently, the copy-back workflow requires manual steps in the PaaS Portal (stop environment, copy databases/blobs from Production, start environment). After the copy, teams must anonymise PII from the copied databases to comply with GDPR before the environment can be used. This anonymisation step cannot be triggered or orchestrated through the platform.

   We would like the EpiCloud module or REST API to expose:

   1. Stop/start an environment without triggering a code deployment
   2. Copy database and blobs from one environment to another
   3. A webhook or callback when the copy operation completes (so we know when to start the anonymisation or "post-copy scripts")
   4. The ability to register and execute approved SQL scripts as a post-copy step (e.g. PII anonymisation, index rebuilds, configuration updates for non-production)
   5. A completion report confirming which scripts ran successfully, for GDPR compliance audit evidence

   Option 4 could take the form of a "post-copy scripts" folder in the project repository that the platform executes automatically after a copy completes, or a managed script execution endpoint that accepts pre-registered/approved scripts.

   This would allow teams to build compliant, scheduled, hands-off environment refresh pipelines without needing direct database access, which most hosted customers do not have.

   As a development team managing multiple lower environments, we want API/PowerShell endpoints to orchestrate the full copy-back workflow, including a mechanism to run registered post-copy maintenance scripts, so that I can automate environment refresh end-to-end without manual PaaS Portal interaction.

   Currently, the copy-back workflow requires manual steps in the PaaS Portal (stop environment, copy databases/blobs from Production, start environment). After the copy, teams must anonymise PII from the copied databases to comply with GDPR before the environment can be used. This anonymisation step cannot be triggered or orchestrated through the platform.

   We would like the EpiCloud module or REST API… more

   9 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Immutable Backups

   Immutable Backups are increasingly becoming cybersecurity and resilience best practice.
   Currently CMS PaaS data is not covered by immutable backups. To further protect us against ransomware attacks and accidental or malicious data tampering having this as a standard or at least optional feature would be highly desirable, providing a reliable last line of defense for fast and trustworthy recovery after a cyber incident or operational failure.
   Any update on timeline for its availability would be very much appreciated.

   21 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Add .NET Counter publication to App Insights on Startup

   There are a whole suite of .NET counters available to use to publish to App Insights. This is a low-lift modification that enables us to gain many insights, directly inside of App Insights Metrics, we can utilize to diagnose issues on customers.

   This enables us to do performance investigations that otherwise require manual intervention (such as downloading .ETL files and opening them in PerfView or capturing dump files and analyzing them).

   We can skip these manual steps and jump write to "close to root causes" by publishing this information. There is little cost and no significant performance degradation associated with publishing this information because Microsoft has designed these metrics to be high performance to collect.

   Having this information available to us enables us to build further features such as success metrics into dashboards for partners to gauge the success of their implementation by taking this information and other information we've build into the Dashboard and surfacing it up in a useful way to the user base.

   There are a whole suite of .NET counters available to use to publish to App Insights. This is a low-lift modification that enables us to gain many insights, directly inside of App Insights Metrics, we can utilize to diagnose issues on customers.

   This enables us to do performance investigations that otherwise require manual intervention (such as downloading .ETL files and opening them in PerfView or capturing dump files and analyzing them).

   We can skip these manual steps and jump write to "close to root causes" by publishing this information. There is little cost and no significant performance degradation associated with… more

   • 

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Dynamic Scaling in DXP - improve performance and reduce costs

   The default hardware SKU for Optimizely is P1V3. P1V3 only has 2 cores and P2V3 has 4 cores. Because the number of cores available to the system dictates the number of default threads the system attempt to regulate, it would be best to deviate away from our current default hardware SKU, P1V3 to P2V3, instead. However, doing so would increase costs which we do not want to do necessarily. This is a proposal to decrease costs while simultaneously increasing hardware resources during peak hours.

   The idea is to increase a customer's lower environment hardware to P2V3 during "working hours" (to be defined by the area the company hosts their hardware in by default), then decrease it after hours.

   The result would be to decrease hardware down to a minimum between approximately 5pm and bump it up again at approximately 9am. But, bump it up to a higher SKU that enables them to operate faster and better

   Based on my calculations, it appears that we could save approximately $700k/yr in doing so (calculation based on retail prices, not contracted prices).

   See the attached spreadsheet for projected reduction in costs.

   A self-service ability would be necessary to be able to temporarily scale up hardware resources. For example:

   • The user would have the ability to push a button to scale up to P2V3 if between an extended hour (between 7am and 7pm).

   • The user would have the ability to scale up additional instances for a short window of time and to keep hardware scaled to P2V3 for, say 4 days per month (4 days of load testing for example).

   This would enable the partner/customer development team to have better control over their resources while simultaneously dropping our costs another $500k-700k approximately.

   The default hardware SKU for Optimizely is P1V3. P1V3 only has 2 cores and P2V3 has 4 cores. Because the number of cores available to the system dictates the number of default threads the system attempt to regulate, it would be best to deviate away from our current default hardware SKU, P1V3 to P2V3, instead. However, doing so would increase costs which we do not want to do necessarily. This is a proposal to decrease costs while simultaneously increasing hardware resources during peak hours.

   The idea is to increase a customer's lower environment hardware to P2V3 during "working hours" (to… more

   • 

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  2 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. 25 Production Service Buses Broken

   We need to define what "working" means for a service bus so that reliability engineering can maintain reliability based on these metrics.

   When a service bus no longer functions, reliability engineering should be equipped with the capacity to upgrade service buses in order to meet a component-specific SLA.

   We need product management to define what "working" means for a service bus so reliability engineering can respond appropriately when a service bus is "broken" rather than having to go back to PM as though we need a exception for every broken service bus.

   We also need monitoring in place to ensure that we receive alerting when the metrics of "broken" happen. This allows us to be proactive regarding broken infrastructure and has the positive outcome of proactively reducing ticket count.

   The attached report shows all 25 broken SBs. The definition of "broken" in this case is a SB with a Count of Active Messages > 1000 for more than 30 consecutive minutes.

   We need to define what "working" means for a service bus so that reliability engineering can maintain reliability based on these metrics.

   When a service bus no longer functions, reliability engineering should be equipped with the capacity to upgrade service buses in order to meet a component-specific SLA.

   We need product management to define what "working" means for a service bus so reliability engineering can respond appropriately when a service bus is "broken" rather than having to go back to PM as though we need a exception for every broken service bus.

   We also need monitoring in place to ensure… more

   • 

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Assess binding settings to resolve resets

   We need to evaluate whether setting the suggested Microsoft setting is worthwhile to resolve resets. As part of that effort, we would have to evaluate the risks of doing so.

   •  

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. IQI Report - App Insights as the Source of Truth

    There are multiple similar functions happening that are similar within Optimizely. They all need to be utilizing the same data a the singular source of truth. They are:

    1. Incident Management, primary data is App Insights.

    2. Deep diagnostics done by Problem Management, primary data is App Insights

    3. App Insights Dashboard

    4. IQI Health Check reporting, primary information (aside from pingdom's availability info which for legal reasons) is Cloud Flare for health information.

    The inconsistency of source data causes issues because we cannot make a consistent presentation of the information when the source being utilized is entirely different.

    It also adds possibility of deviation of information because CloudFlare adds network hops and the possibility of transforming HTTP Status Codes, etc. So, the information can be altered in an unproductive way.

    If we want to add CloudFlare reporting, we should add targeted CloudFlare specific reports to the IQI report. These should identify discrepancies within the CloudFlare environment that are frequently done as differentials between App Insights and CloudFlare - such as delays in response from CloudFlare that are not caused by backend systems.

    There are multiple similar functions happening that are similar within Optimizely. They all need to be utilizing the same data a the singular source of truth. They are:

    1. Incident Management, primary data is App Insights.

    2. Deep diagnostics done by Problem Management, primary data is App Insights

    3. App Insights Dashboard

    4. IQI Health Check reporting, primary information (aside from pingdom's availability info which for legal reasons) is Cloud Flare for health information.

    The inconsistency of source data causes issues because we cannot make a consistent presentation of the information when the source being utilized is entirely different.

    It also adds possibility of… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  1 comment  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Identify and Aid Customers with Production Live-Locks

    There's the concept of a "dead" lock and a "live" lock. A live-lock is essentially a race condition within a production environment. It causes stair stepping of CPU usually until the server crashes.

    This often happens when a developer accidentally uses a non-thread safe object in a multi-threaded manner.

    The object (for example a HashSet) being used needs to be identified and a thread safe type needs to be replaced so that the live-lock goes away and the CPU goes back to normal.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Down-Sampling Service Bus App Insights

    Much of the log analytics costs come from voluminous amounts of service bus activity that is largely useless for analytics purposes. We could generally use a fraction of the analytics and we would be just fine.

    For diagnostic purposes, we generally need to inspect the contents of the service bus itself to identify problems.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Consider shifting from Adaptive Sampling to Fixed Sampling

    There's a known bug in Adaptive Sampling that prevents us from getting accurate analytics from App Insights. It largely calls the values of App Insights largely into question because we cannot tell when the metrics within App Insights are accurate or not.

    Moving from Adaptive Sampling to Fixed Rate Sampling resolves this issue, but it also can cause an increase in log analytics and the possibility of exceeding the log quota.

    If we can come up with a weekly way to determine the appropriate sampling rate for a given type of log data for a customer and tweak the analytics fixed sampling rate on a weekly basis, that would be preferable. That combines the best of both worlds.

    https://www.google.com/search?q=known+microsoft+issue+in+app+insights+adaptive+sampling+values&rlz=1C1CHBF_enUS1003US1003&oq=known+microsoft+issue+in+app+insights+adaptive+sampling+values&gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBCTEyMDM5ajBqN6gCALACAA&sourceid=chrome&ie=UTF-8

    There's a known bug in Adaptive Sampling that prevents us from getting accurate analytics from App Insights. It largely calls the values of App Insights largely into question because we cannot tell when the metrics within App Insights are accurate or not.

    Moving from Adaptive Sampling to Fixed Rate Sampling resolves this issue, but it also can cause an increase in log analytics and the possibility of exceeding the log quota.

    If we can come up with a weekly way to determine the appropriate sampling rate for a given type of log data for a customer and tweak the analytics… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Identify and Communicate Crashing Instance Causes by Exception/Log Inspection

    Due to my elevated level of access nobody on the team gets these errors emails from Microsoft except Erik.

    We need an easy way to address these with customers through the ticketing system.

    These are causing instances crashes for the sites. Here's an example of what's happening on moco.

    Here are the email threads I'm receiving from Microsoft that shows they're having outages.

    •  

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. IP Address restriction in Cloudflare

    It would be great if we could configure an IP Address whitelist in Cloudflare so that we only allow a specific set of source IP Addresses to be allowed to access our DXP instances. This will allow us to block public access to non-production environments

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. When there are errors on the servicebus we don't log it. It would help if we logged errors for troubleshooting purposes.

    When there are issues with the servicebus it is not possible to see what went wrong many times. You can go to the servicebus and look at the graph and see that there are "server errors" and "user errors" and "throttled messages"but there is no way to see the details of the server errors or the user errors.
    Some times we can see a log entry in the CMS logs but not always and I guess it depends on the type of error.
    If we had more information it would help when troubleshooting customers having problems with the servicebus.

    15 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  1 comment  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Allow disabling warmup for integration and preproduction

    Integration and preproduction environments are sometimes protected by IP-whitelists and in those cases the warmup step always fails with status code 401. The warmup system waits for about 15 minutes until these requests time out. This increases delivery times to these environments specially when CI/CD is set up.

    Ex:
    2026-03-10 12:40:24 Information Starting to warm up the targets slots...
    2026-03-10 12:40:25 Information Preparing target slot for Go Live (<masked>/slot) (warming up the slot)
    2026-03-10 12:52:21 Warning Timed out waiting for all instances for webapp <masked> and slot "slot" to become ready!
    2026-03-10 12:52:21 Information Validating deployment ID uniqueness between slots for <masked>.
    2026-03-10 12:52:22 Information Deployment ID validation passed.
    2026-03-10 12:52:22 Information Sending webrequests to validate the slot (<masked>/slot)...
    2026-03-10 12:52:55 Warning Site with URL http://<masked>-slot.dxcloud.episerver.net/ responded with error code: 401 (Unauthorized)

    Below are some suggestions to resolve this issue:
    1. Warmup system should respect WarmupOptions.Disable in appsettings.
    2. Paas portal should have options to disable warmup for selected environments.
    3. Deploy script should cancel the warmup step if the start page fails with status code 401.

    Integration and preproduction environments are sometimes protected by IP-whitelists and in those cases the warmup step always fails with status code 401. The warmup system waits for about 15 minutes until these requests time out. This increases delivery times to these environments specially when CI/CD is set up.

    Ex:
    2026-03-10 12:40:24 Information Starting to warm up the targets slots...
    2026-03-10 12:40:25 Information Preparing target slot for Go Live (<masked>/slot) (warming up the slot)
    2026-03-10 12:52:21 Warning Timed out waiting for all instances for webapp <masked> and slot "slot" to become ready!
    2026-03-10 12:52:21 Information Validating deployment ID uniqueness between slots… more

    7 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. rolling restart flag

    Please make i possible to be able to flag for a rolling restart (one instance at a time) when executing deployments -through DevOps / GitHub release pipelines.
    -Note:
    old feature request disappeared it seems:
    https://world.optimizely.com/forum/developer-forum/Developer-to-developer/Thread-Container/2023/5/is-it-possible-to-do-a-rolling-restart-from-an-api-call-powershell-cmdlet-or-something-similar/

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. DXP Management Portal

    Restart Site - Have "Restart one instance at a time" be checked by default since not checking this can cause serious issues upon restart.

    Also adding the checkbox state to the confirmation message so users are aware.

    •  

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Future Consideration  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Google Tag Gateway

    Support Google Tag Gateway with Cloudflare.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  1 comment  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating