You Can’t Fix What You Can’t See: A Step Back for Microsoft 365 Search

A few days ago, fellow MVP Reshmee Auckloo notified me that the PnP PowerShell command Get-PnPSearchCrawlLog is about to be removed (see Deprecate Get-PnPSearchCrawlLog cmdlet #5229).

For me—and for anyone who works seriously with Search in Microsoft 365—this is a significant step backwards. The output of this command has, until now, been the only reliable way to get Microsoft Support to acknowledge and act on real search issues, instead of falling back on the default response: “please try to reindex the library again” [sic].

With this command gone, an uncomfortable question remains:

How are we supposed to troubleshoot a broken search indexing service now?

How are we going to fix a broken search indexing service now?

Anyone who has spent time in the trenches with Microsoft 365 Search knows this already: the SharePoint reindexing service is not 100% reliable. It is not uncommon for reindexing jobs to be heavily delayed—or simply never run at all. When that happens, every search‑driven solution suffers: intranets, hubs, vertical search experiences, PnP Modern Search, Copilot grounding, you name it.

Microsoft has not documented how this service actually works. We are left guessing. From years of observation, it appears to operate on a priority‑based schedule, where jobs are postponed whenever the farm is under load. The important detail here is that your tenant does not exist in isolation. Even if your own tenant is quiet, another tenant in the same farm running a large migration can effectively starve your reindexing jobs.

And let’s be very clear about the contractual reality: Microsoft provides no SLA for reindexing. If your content is indexed once a month, that is—officially—perfectly acceptable.

The API used by Get-PnPSearchCrawlLog has been marked as deprecated for some time, so the retirement itself is not entirely surprising. What is concerning is that, as far as I know, there is no replacement. No alternative API. No supported diagnostic tooling. No new way to prove that search indexing is failing on the service side.

I am sure the decision to shut down the API makes sense when viewed in isolation—security, performance, cost, or architectural cleanup. But taken in context, it leaves customers, consultants, and support engineers completely blind. Without crawl logs, there is no evidence. And without evidence, search issues are trivially dismissed as “content problems” or “just reindex again”.

This change effectively removes the last tool we had to demonstrate—objectively—that the problem is not configuration, not metadata, and not user error, but a failure in the Microsoft‑managed indexing pipeline.

If Microsoft expects customers to build business‑critical solutions on top of Search, then observability is not optional. I strongly urge the SharePoint product team to provide a supported alternative—because right now, we are being asked to trust a black box, without logs, without SLAs, and without recourse when it fails.