Monitoring Benefit
This is the SharePoint row of Service Level Availability. It reports what proportion of the selected period SharePoint Online was available, as measured by the site operations ENow performs against your tenant.
SharePoint has the widest blast radius of any workload here, because so much sits on top of it. Teams files, intranet pages, document libraries and any application storing content in SharePoint stop together — and users report the thing in front of them rather than SharePoint itself.
For how the figure is calculated, the two surfaces it appears on, the Node Type filter and where the thresholds live, see Configuration - Service Level Availability.
What feeds this figure
SharePoint is measured by more separate operations than any other workload, which is why its check count runs well ahead of the others. In the report's detail grid the failures appear under:
| Test Name | What it exercises |
|---|---|
SharepointUploadDownloadTest |
Writing a document and reading it back |
SharePointCreateFolderTest |
Creating a folder |
SharePointRenameFolder |
Renaming it |
SharePointCreateListTest |
Creating a list |
SharePointCreateListItemTest |
Adding an item to a list |
SharePointSiteSearchTest |
Searching the site |
Which test failed is the diagnosis. This is the one workload where the test name usually tells you the answer before you read the error — list operations failing while documents succeed is a very different problem from everything failing at once.
Expect the complaints to name something else
| What users report | What it may actually be |
|---|---|
| "Files won't open in Teams" | Teams files live in SharePoint. Teams itself may be perfectly healthy. |
| "The intranet is down" | SharePoint. |
| "The [internal application] is broken" | Anything storing its data in SharePoint lists fails with it — watch the list tests. |
| "I can't get to the shared drive" | Frequently a mapped or synced SharePoint library. |
| "Search isn't finding anything" |
SharePointSiteSearchTest. Search can fail while content is perfectly reachable. |
When several unrelated-sounding complaints arrive together, this row is a fast way to establish they are one incident rather than four.
Reading it against OneDrive
SharePoint and OneDrive share a platform, so the pair is diagnostic. Both dipping at once points at the platform and should be worked as a single incident. SharePoint dipping alone is narrower — check site-level permissions, the availability of the site the tests target, and whether anything changed on it.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
| Sustained 0% uptime | Usually collection or access rather than an outage. Confirm the test account still has permission to the site the checks target — permissions change far more often than SharePoint fails. |
| Uptime drops after a site or permission change | The most common real cause. A site moved, archived or re-permissioned leaves the checks pointing at something they can no longer reach. |
| Only the list tests failing | Narrower than an outage. Check the specific list the tests use, and any recent change to its columns or permissions. |
Only SharePointSiteSearchTest failing |
Search indexing rather than availability. Content is reachable; finding it is not. |
| SharePoint and OneDrive both dip | Platform-level. One incident, not two. |
| Users report Teams file problems while Teams uptime is healthy | Look here. Teams files are stored in SharePoint, so a SharePoint incident presents as a Teams complaint. |
Comments
0 comments
Article is closed for comments.