SharePoint Server's Distributed Cache service, built on the AppFabric caching framework, is one of those background components that nobody thinks about until it breaks. When it does, the symptoms are rarely obvious. Newsfeeds stop updating, authentication cookies behave oddly, page load times climb, or the service simply shows as stopped in Central Administration after a reboot or a patch. We first wrote about a specific case of this back in 2013, on SharePoint 2013. The underlying cache cluster mechanics have carried through largely unchanged into SharePoint 2016 and 2019, so the same troubleshooting approach still applies to any on premises farm running one of those versions today.
Start by checking the cluster's actual health
Open the SharePoint Management Shell as a farm administrator and run:
Use-CacheCluster Get-CacheHost
This tells you which servers the cache cluster thinks are active, and whether any host has silently dropped out. A server that rebooted, had its Distributed Cache service disabled, or lost network connectivity to the rest of the farm will often still appear configured in SharePoint while quietly missing from the actual cluster.
Confirm the service instance status per server
On each server that should be running Distributed Cache, check its status with:
Get-SPServiceInstance | Where-Object {$_.TypeName -eq "Distributed Cache"}If a server shows as anything other than Online, restarting the AppFabric Caching Service in Windows Services on that machine is the first thing to try. If that does not resolve it, the more thorough fix is to remove and re add the Distributed Cache service instance on that specific server:
Remove-SPDistributedCacheServiceInstance Add-SPDistributedCacheServiceInstance
Run the removal on the affected server, confirm the rest of the cluster is healthy, then add it back in. This forces that server to rejoin the cluster cleanly rather than trying to recover a corrupted cache state in place.
Worth checking while you are in there
Distributed Cache problems are also a common side effect of applying a cumulative update without fully completing the SharePoint Products Configuration Wizard on every server. If you have not already confirmed your farm's exact build number and that every server matches, that is worth doing at the same time. We cover exactly how in our guide to checking your SharePoint farm build version.
If your farm is still on SharePoint 2016 or 2019, keep in mind that extended support for both ended this month, so a Distributed Cache issue today is also a good moment to have the bigger conversation about what comes next. Our cloud migration services and Microsoft 365 team can help you weigh an in place upgrade to Subscription Edition against a move to SharePoint Online. Get in touch if you want a second opinion on a stuck cache cluster or the bigger picture around it.