...
We have staging environments for customers to test their configurations before making those changes in the production environment. We do have ISM staging environments in NA and Europe regions like we have production environments.
Staging environments are currently available like production environments 24x7. However, these environments are being used only by those customers who want to test their changes if they have any. As such, we see that these environments are sparingly used but are up and running all the time. It’s not an optimal use of these environments from a cost perspective.
To optimize the cost, we would like to make some changes as detailed below:
...
To optimize the infrastructure costs that we incur in staging/trial environments.
What’s the impact to on the customer?
When the system is idle for 30 min, it will go offline. During that time, if a user tries to access staging environment, he will have to follow the instructions to bring up his instance. Probably he will have to wait for 2 to 5 minutes (max) to access the staging environment.
...
Pl note we will monitor only application access to identify if the system is idle.
We don’t expect a customer to run some tests behind the scene using Rest APIs on our staging environment. Of course, they can test their integrations when the system is up. But customers can’t assume the systems will be up and running 24x7.
We also plan to archive any attachments that they have that are older than 30 days in staging environment. This is to keep the system lean so that it can be brought up quickly.
Screenshots
When a users user tries to access the staging environment that’s offline, he will be directed to the below flow to spin the environment up:
...
After clicking the above link, user will be prompted:
...
Once the environment is up, the user will be automatically redirected to that ISM/ Luma web page.