SharePoint PnP logo

New-PnPSite fails with “SiteStatus” : 3

This post was most recently updated on May 16th, 2019.

Reading Time: 3 minutes.

While running “New-PnPSite” or actually any other site creation, method in PowerShell or programmatically, the site creation fails and you get an error like the one below back:

New-PnPSite : {"d":{"Create":{"__metadata":{"type":"SP.Publishing.CommunicationSiteCreationResponse"}, "SiteStatus":3, "SiteUrl":""}}}

Ouch! Where does this come from? In the code of New-PnPSite, the actual function call is shown below:

var results = ClientContext.CreateSiteAsync(creationInformation);
var returnedContext = results.GetAwaiter().GetResult();


So, the error is not thrown by PnP cmdlet, but rather comes from SharePoint CSOM. This is pretty normal and not surprising, but means we can’t debug it that much, as CSOM is not open source.

Alright – what can we do to fix this? There’s a couple of things – but first, let’s take a look into the call itself and its SiteStatus value!

What does SiteStatus in that response mean?

Okay – your New-PnPSite didn’t seem to result in a new site being created, but rather you got an error and a status code that doesn’t tell you much. What now?

My understanding of the status codes is the following:

  • 1
    • We’re getting there! Please wait, you’ll get your site eventually.
    • Throttling or high resource usage means you’ll get your site a bit later.
    • Implement a logic for backing off or sleeping, if you need the URL of the group or if you need to apply any modifications to it afterwards.
  • 2
    • Site created, you’re good!
    • Should also return the URL.
  • 3
    • Fatal error. All hope is lost.
    • You’ll need to handle this in your code, by implementing a fallback logic or just handling the error.

Weirdly enough, the best source I have for these status messages is this conversation on GitHub:

Reasons and resolutions

Multiple reasons can cause the issue. One of the most typical ones from my experience is that the URL was already in use.

Sounds simple, right? However, this doesn’t mean that there actually would be a site with that URL. The URL is still reserved also for removed sites that are in the recycle bin, and there’s no GUI for removing these sites from said bin.

Luckily, we do have PowerShell commandlets to do this task for us!

Below is the PowerShell commandlet to see which sites are in the second stage recycle bin:

Connect-SPOService -Url "[]"

To get rid of one or more of them, you can call Remove-SPODeletedSite. See this blog article on how to do that: !

Could this be a Microsoft issue?

Okay – maybe it wasn’t your fault, after all! If the site wasn’t in the recycle bin and PnP libraries work as they should, it’s only this site creation that’s not working… Well, maybe it was Microsoft messing it up all along! This might especially be the case, if the issue persists for site creation using different methods (GUI, CSOM, 3rd party tools) and different URLs.

There’s a bug ticket about this reported on PnP GitHub, but truthfully, I don’t think the issue is ever in the PnP code – it’s usually an underlying issue in the datacenter:

The resolution could be to just contact Microsoft Support and get them to flip a switch. Sorry – no silver bullets here! 🤔

0 0 vote
Article Rating
Notify of
1 Comment
most voted
newest oldest
Inline Feedbacks
View all comments