Static Web App Already Has Maximum Number of Staging Environments

  • 6 Min To Read
  • 14 May, 2023


I have recently had a build failure on Github when making a change to my blog. When I make changes to my blog I can create them on a separate branch, this allows me to test changes away from the “production” version before publishing them. When I raise a pull request, a github action will build my site and publish the code to the Azure Static Web App I’ve provisioned for this site. A web app has a number of “slots” which can be used for publishing versions of your code. This is really handy since I can publish changes and view the entire site on a complete separate URL before publishing them to the “real” URL. The free plan allows me to have 3 additional slots which means I can only have three pull requests open at any one time.

Error raised

I made some changes today and the build failed with the following message;

The content server has rejected the request with: BadRequest
Reason: This Static Web App already has the maximum number of staging environments (3). Please remove one and try again.

So the Static Web App hosted on Azure is saying that it will not let me publish my code because I have run out of staging environments…in other words I have no more preview slots available to publish to. I’m running the free plan and I have reached my limit! That shouldn’t really happen though, so I need to work out why.

Check Github

Each slot will have a separate version of my code deployed to it. So the first thing I should check is whether I already have three pull requests open that I haven’t dealt with previously. If I head over to Github and open the repository I can see how many pull requests are currently open.

the image shows the headers from my repository, against the pull requests heading there is a number 1, implying that I only have one pull request open

I can that I only have one pull request open, so this is not the cause. Also observe in the screenshot that the pull request number is #67.

Check Web app

The next thing to check is why I’m out of slots. A basic web app will have one production slot which will typically be connected to your main branch. This is the version of your code that is presented if you go to your normal URL. It will also have three “preview” slots. This can be viewed in the Environments section of your web app in the Azure Portal.

the image shows the environments section of the web app from the Azure portal, it shows one main production slot and also has three preview slots, they are numbered #64, #65, #66 and area available for viewing

So from this I can see that something isn’t right. In the screenshot above you can see that there are three preview slots present and are all associated with historic pull requests. These slots should only exist during the life of a pull request and once the pull request is complete, they should be purged. This ensures that during normal processing I will never run out of slots because (at least in theory) I will never have too many incomplete changes open at once.

Supposing that the pull requests listed for each slot were still open, then this would be a code review problem - I am trying to add a fourth set of changes for review but I already have three previous pull reqeusts that I haven’t reviewed (#64, #65, #66). If that was the case, then I would resolve this by completing all the historic pull requests first therefore, freeing up the slots.

Identifying the issue

In this situation though, it seems to be a process problem. As I said earlier, once a pull request is completed my github action should purge the associated slot and so something isn’t quite right with my github actions. It would appear that I’ve introduced this issue when adjusting my github actions previously (doh). Somewhere along the way I made a change to my actions and in doing so left out an important block of code from my pull request YAML file.

Checking through my historic code, I can see that the last job in the file used to be one that occurred if the event was the closure of a pull request. It uses the static web apps deploy task to trigger the closure of a preview slot. Reinstating this block of code as the final step should resolve my issue. This block of code has an if statement that filters by an event_name of pull_request and an action type of closed, meaning that it will only be run if the pull request is closed.

    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/[email protected]
          azure_static_web_apps_api_token: ${{ secrets.PORTAL_DEPLOYMENT_TOKEN }}
          action: "close"

Cleaning Up

Unfortunately, this won’t clean up the historic issues, so first I will need to remove the preview slots related to pull requests I’ve already closed. I can do this by going back to the Azure Portal, navigating to the environments section of the webapp, clicking one or more of the slots and pressing the delete button;

image shows the environments section, all three preview slots are ticked, pressing the delete button will remove all preview slots

Testing the change

Once I’ve adjusted my yaml file I can rerun my github action to see if the preview site gets built.

image shows the outcome of the next actions run, the status is success

Checking the preview slots in Azure, I can see that my code has been published, I can now go ahead and preview my changes using the browse link to the right of the slot;

image shows environments section of the webapp, the historic slots have gone, one slot is now present which is labelled as #67 there is a browse link on the far right allowing my to open my changes to review them

Checking the fix has worked

We’re almost done but the last thing to check is whether my fix to the github actions has worked. The publishing of the preview slot has succeeded simply because I purged all the historic preview slots. The real test is whether the lost provisioned for #67 will be purged once I’ve approved the pull request.

Now I’ve been able to review my changes, I’m happy that it’s ready for publishing so I will go ahead and approve the change. This will write my changes back to the main branch and trigger my github action again. If everything has worked as intended, my changes will be published to the production environment and the preview slot will be purged.

First I will approve the pull request, this will merge my code back to the main branch;

image shows the pull request successfully merged

Next I want to check whether my conditional step has been run by the github actions.

image shows the github actions summary, the publish step has been skipped and the close pull request job that was reinstated has been run

Things are working as intended! The next run ignored the publish because the pull request is closing, instead it has triggered the purge step as intended.

Ok, so I’ve cheated a little bit here…you might notice that my screenshot is from a different pull request (#68), that’s because I had to fix it twice. In order to test the actions worked properly, I had to merge the pull request, but it didn’t quite work as intended first time, so I had to adjust it on #68.

Final check, has the preview slot been purged…

image shows the environments section again, there is one production slot and no preview slots

#67 is no more! I can now confirm that this error is resolved. I’m now going to go away and have a word with myself about doing a better job of reviewing my code in future :)


If you made it all the way down here, thanks for reading my post and enjoy your day. If you have any comments or suggestions, please leave them below...

the jedi order logo