M37

One delete starts several clocks, and the shortest one decides

This is the material behind the video. Microsoft documents a recovery window for very nearly everything you can delete in Microsoft 365, and taken one at a time those windows are reasonable: different data has different recovery machinery behind it, and each number is defensible on the page it is written on. What is hard is that a single administrator action starts several of them at once, on pages that do not reference each other, and the shortest of them is what a restore is actually limited by.

The record below is 38 documented recovery clocks, read off 19 Microsoft pages that were fetched on 5 September 2026 and kept as bytes exactly as they were served. Every number is quoted from the stored copy, and the quotes are checked mechanically before this page can be generated: the build refuses the record if a quoted sentence is not a verbatim excerpt of the page it names, or if a number a row asserts does not occur in that row’s own quote. The hash and fetch time of each page are at the bottom.

We ran no restore. We have no Microsoft 365 tenant and we are not selling one. This is the documentation rather than a product test, and nothing on the page says what any organisation should buy or configure. Where a line goes further than the sentence it sits next to, it is marked as our reading and it is ours.

The numbers in the video

Each of these is a count of what the documentation states, and each one carries what it does not mean. A bare figure about backup reads as advice, and none of these is advice.

One action, several clocks

Each block below is one thing an administrator does, and the windows it opens. The clocks are listed in the order the documentation presents them rather than by length, because which one a reader would have found on their own is part of the point. The clock that limits the whole action is marked in place: it is the one that decides what comes back, and it is rarely the one printed nearest the button.

an admin deletes a departing employee's user account

Three separate 30-day clocks start together and are documented on three pages that never reference each other: the identity object, the mailbox, and the OneDrive. They look like one 30-day grace period and behave like one until day 31, when the OneDrive stops being a folder someone can browse and becomes a PowerShell restore out of a bin that eDiscovery cannot search. The site the files land in then runs 93 days while the account underneath it goes read-only at 60 unlicensed days.

an admin deletes a Microsoft 365 group, or the SharePoint site behind it

The clearest disagreement in the harvest, and Microsoft states it plainly: the site is kept 93 days and everything else about the group is kept 30. Restoring on day 40 succeeds, the button works, the site comes back, and returns a shell whose mailbox, calendar, Planner and Teams channels were destroyed ten days earlier. The 30-day number is the one that decides, and it is the one printed furthest from the delete button.

a user empties Deleted Items on a mailbox with nothing on hold

One gesture, three outcomes. Messages get 14 days. Calendar items in the same folder under the same setting get 120. A folder gets nothing at all, it is hard deleted, explicitly beyond the reach of litigation hold, while its contents survive on the ordinary 14-day clock. So the recovery returns the mail and loses the filing, and the item most likely to still be recoverable a month later is the meeting nobody was looking for.

a user saves over the same document until the version limit is passed

Every recovery procedure in the other chains starts at a recycle bin, and this one never reaches one. Versions pushed past the library limit are marked for permanent deletion and bypass the bin, so the 93 days that governs deleted files is irrelevant to data destroyed by ordinary editing. Nobody deletes anything, no event appears anywhere a user would look, and the admin button labelled as storage housekeeping does the same thing on purpose.

an admin removes a licence to stop paying for it, leaving the account in place

No deletion happens anywhere in this chain, which is why it is the one most likely to be run by someone in finance. The mailbox is destroyed at 30 days. The OneDrive is still there, read-only at 60, archived and billable at 93, and at 365 cumulative unpaid days Microsoft states it is deleted even if retention policies, settings or holds exist on it, the only clock in the record documented to outrun a hold.

Where two pages word it differently

Places in the harvest where two Microsoft pages say different things about the same subject. Both sentences are real and both are live, and an administrator reads one of them and not the other. They are not all the same strength, which is why each one’s own line says what it is: one of these is a straightforward conflict about a date, and the other we downgraded to a wording inconsistency after a reader with no stake in the answer told us the first draft had overstated it. Either way these are observations about the published record and not a charge against anyone — documentation of this size is written by many people over many years, and what interests us is that a reader has no way to tell which page they are on.

when the deletion clock on an unpaid, unlicensed OneDrive actually starts and finishes

Twelve months and 365 days are the same length, and these are not the same clock. The OneDrive page starts it at the archive event, which its own text puts on the 93rd unlicensed day, and states it as elapsed time. The unlicensed-accounts page starts it when the account becomes unlicensed and states it as CUMULATIVE unpaid days, which pause whenever billing is on. For the same account the two readings put the deletion date roughly 93 days apart, and only one of them can be paused by paying. Our reading: the unlicensed-accounts page is the more specific and more recent of the two and should govern, but an admin who read only the OneDrive page would date the risk wrongly and would not know the clock can be stopped.

how two pages word the 500-version default, and why it is a wording inconsistency rather than a contradiction

DOWNGRADED 2026-09-05 by the orchestrator after a context-minimal cold reader doubted it, correctly. The first draft of this entry called the two sentences "opposite predictions about the same event", a cap that destroys the 501st version against a floor that guarantees it, and that overstates the harvest. The page whose subject this actually is, version-history-limits, settles it in the direction of a cap: "if a library is configured to store 500 major versions, no more than 500 versions is stored for each file or item." So the operative rule is a ceiling, and retention-sharepoint's "retains a minimum of 500 major versions" reads as loose wording in a section about how retention interacts with versioning rather than as a competing guarantee. It is kept in the record because sloppy wording on a destructive default is worth showing, and because a reader who met only that sentence would form the wrong belief. It was cut from the video, where it would have been asserted as a contradiction with no room for this paragraph.

Every clock in the record

One row per documented window. The window is the default the page states, so a row marked configurable can be longer or shorter in a given tenant and the row’s own panel says what ceiling, if any, the page names. Where a row says there is no way back, that is what its quoted sentence says, and it is not a window of nothing days — it will not lead an ordering by length, and the two rows whose clock the documentation describes without giving it a length are kept apart from both. Opening a row shows the verbatim sentence, what we make of it, and the page it was taken from.

How this was built

The pages every quote came from

Each link goes to the page as it stands now. The quote beside each row came from the copy taken at the time below, and the hash is of that copy. Microsoft edits its documentation, so if a page and its stored copy have diverged, the divergence is the interesting thing and we would like to hear about it.

• data-resiliency · 1 row quotes it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/compliance/assurance/assurance-sharepoint-onedrive-data-resiliency
  sha256 fe1cedf44e165cc5992ae751f7778fff143b9fb157420412249e6f9fd0474aa9
• delete-restore-mailboxes · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/delete-or-restore-mailboxes
  sha256 fda153edfd076eaefc0f225589bff908d00db36eb020b128285f3367a721445a
• deleted-item-retention · 1 row quotes it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-user-mailboxes/change-deleted-item-retention
  sha256 1c2f6823d7f0e0098868f6fdcfcc667e7850763f7a050f8de641f1788b265339
• inactive-mailboxes · 3 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/purview/inactive-mailboxes-in-office-365
  sha256 8d9259f414436298479366b26839bd67301ef6c16259c31394f2bac6f0934b62
• m365-backup · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/microsoft-365/backup/backup-overview
  served from https://learn.microsoft.com/en-us/microsoft-365/backup/backup-overview?view=o365-worldwide
  sha256 581744c02db3937a252158d26baf5d2e31abb15a4f46806e7e47a08464a8daeb
• onedrive-retention-deletion · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/sharepoint/retention-and-deletion
  sha256 35fe3e6cd3d05b315b063086f29667781d9cc51e022334f9d4930c361c652098
• recoverable-items · 3 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/exchange/security-and-compliance/recoverable-items-folder/recoverable-items-folder
  sha256 ff101a91ce102d21c0e1dfc42c3bcda32954546a3adcd594f2e02e5a786931a9
• restore-deleted-group · 1 row quotes it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/microsoft-365/admin/create-groups/restore-deleted-group
  served from https://learn.microsoft.com/en-us/microsoft-365/admin/create-groups/restore-deleted-group?view=o365-worldwide
  sha256 4c1a001f8d9bd5c909737a80bebe342127cb2024e12506ba9c97cc93b1f2fc60
• restore-deleted-site · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/sharepoint/restore-deleted-site-collection
  sha256 660ef2d20412d3190ac2704e54502052ada9d70bb8ae5a0d33b16354a29ec9d7
• restore-deleted-user · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/entra/fundamentals/users-restore
  sha256 7bb38390c6ec6ffdcd5134c479b711eced737edb19b645977ab1c43d30ce96a7
• restore-onedrive · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://support.microsoft.com/en-us/office/restore-your-onedrive-fa231298-759d-41cf-bcd0-25ac53eb8a15
  served from https://support.microsoft.com/en-us/onedrive/restore-your-onedrive
  sha256 437b12558784a18a9a99db6a63f38c09a3785273cc44bcba280d5f844c3090a6
• retention-policies · 1 row quotes it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/purview/retention
  sha256 78d7a2e5ef6163d03f59090ba1d670f3e24f50b34796d528c200fb11aa3f4874
• retention-sharepoint · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/purview/retention-policies-sharepoint
  sha256 01d626170d879aaa5119ac7581a92be6ef8cdb58a8030b3df2f1caa54b8e4f2a
• retention-tags · 1 row quotes it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/exchange/security-and-compliance/messaging-records-management/retention-tags-and-policies
  sha256 5b87307c136b1e8b3c8295c1a6738e6be625d48a747b40d55c1b4cba14ddca40
• site-collection-recycle-bin · 3 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://support.microsoft.com/en-us/office/restore-deleted-items-from-the-site-collection-recycle-bin-5fa924ee-16d7-487b-9a0a-021b9062d14b
  served from https://support.microsoft.com/en-us/sharepoint/admin/restore-deleted-items-from-the-site-collection-recycle-bin
  sha256 2e6d9a4d49ed0d1d2faa6d1fb8fe57f02f901840dfecd29eda8ec600f3952d1a
• teams-recording-expiration · 4 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/microsoftteams/manage-teams-recording-expiration-policy
  sha256 b672cd6f94710055fc9c968cab4961b4c4c92f3ed6e5e07975a27ac8c62a9c02
• teams-retention · 1 row quotes it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/purview/retention-policies-teams
  sha256 76e6403c31ed15a3b7479fe173252588444146315df7e16d01394611d1837068
• unlicensed-onedrive · 3 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/sharepoint/unlicensed-onedrive-accounts
  sha256 10d27ec078939847cdfd63afdfa901aaf80255289c57fe155eddc2e43f3ba4a3
• version-history-limits · 2 rows quote it · fetched 2026-09-05 at 12:07 UTC
  https://learn.microsoft.com/en-us/sharepoint/document-library-version-history-limits
  sha256 bb30edee51b2fdda93df0675d2a6af13b94d448bfeef299a77ee6a5fa9bc3763

Ask us to check something

If your organisation runs on a platform that makes claims about what it keeps, we will do to it what we did here: read the documentation, quote it, and write down where its own pages disagree with each other. That is a record you can hand to an auditor or take into a renewal conversation, and it is a different thing from a vendor’s summary of itself.

What we would actually do, concretely: harvest and hash the relevant pages, build the same kind of table, walk the chains that matter for your data, and give you the stored copies alongside it so the whole thing stays checkable after the pages change. We read everything that arrives and we answer, including when the answer is no.