Snapshots lie: why 90-day trends change decisions

Every Microsoft 365 review starts with a number that is true and useless. Storage at 68% of quota. 412 of 450 licences assigned. Last month's Azure bill, €4,180. Each one is correct on the day it was read, and none of them says whether you are looking at a steady state or the middle of a slope. Below are four metrics where we went back and read the same tenant twice — once as a point, once as a line — and the line changed what we would have done.

Storage: 68% of quota, and the wrong remedy

A SharePoint tenant at 68% of quota is a tenant nobody schedules a meeting about. Read as a line instead, the same tenant had added roughly four points a month for five months — which turns "we're fine" into "we buy storage or we clean up before the winter, and the decision is due now, not in Q2."

The trend is not something you have to build. Graph has a dedicated function for it: getSharePointSiteUsageStorage returns "the trend of storage allocated and consumed during the reporting period", and the CSV it redirects to carries a Report Date column — one row per day, up to D180. The per-site and per-mailbox reports are the opposite shape: getMailboxUsageDetail also takes a period, but every row is that mailbox as of the Report Refresh Date. Passing D180 does not give you six months of mailbox sizes. It gives you today's sizes, filtered by six months of activity.

The slope also names the remedy, which the snapshot can't. In the tenants we've measured, files are a minority of the bytes: 33% to 51% of a SharePoint site's storage was version history, recycle bins and preservation hold, and 42% to 65% of a OneDrive's. A point-in-time number invites "ask people to delete things", which recovers none of that. Two months of slope tells you whether the growth is documents arriving or versions accumulating — a different problem with a different fix.

Sign-ins: a trend you are not allowed to have

Ask for a quarterly view of sign-in anomalies and the platform simply says no. Microsoft Entra keeps sign-in and audit logs for seven days on Free and 30 days on both P1 and P2. Paying more does not buy more history: 30 days is the ceiling. Risky sign-ins are the one exception, at 7 / 30 / 90 days by tier.

Two consequences people discover late. First, the 90-day question can only be answered by something that copied the data out before it aged — Azure Monitor, a storage account, or a tool that keeps its own snapshots. Second, retention changes are not retroactive: upgrading a Free tenant to P1 today surfaces the seven days that still exist, not last month's. The upgrade you make during an incident buys you nothing about the incident.

Licences: the number with no yesterday

"412 of 450 assigned" is the most-quoted figure in any tenant review, and it is the one with the least information in it. Look at the subscribedSku resource: consumedUnits, prepaidUnits, servicePlans, capabilityStatus — eleven properties, not one of them a date. There is no "as of", no history, no change event. The API is physically incapable of telling you whether 412 was 380 six weeks ago or 430 last quarter, and those two tenants need opposite decisions at renewal.

The same blind spot sits under licence waste. Thirty-eight spare seats reads as healthy headroom or as a stalled rollout depending entirely on the direction, and the direction is not in the payload.

Cost: the snapshot moves after you take it

Azure spend is the one place where two people can read the same month and both be right. Cost Management data is estimated until an invoice is generated, estimated charges for the open period are updated six times a day, and the current period's charges can be rerated until the invoice closes — which itself happens up to 72 hours after the billing period ends. Latency compounds it: 8 to 24 hours for EA and MCA subscriptions, up to 72 hours for pay-as-you-go.

So a screenshot taken on day 2 of the month and one taken on day 30 are not the same kind of object, and "last month spiked" is a claim that can quietly stop being true. A trend built from daily reads is not just more information than a snapshot here — it is the only version that survives contact with the final invoice, because you can see the same day restated instead of remembering it wrong.

Three kinds of metric, three amounts of work

After doing this across a handful of domains, everything sorts into three buckets, and the bucket decides how much effort a trend costs you.

One trap worth knowing before you trust a long window: history can be rewritten underneath you. When a user account is deleted, Microsoft removes that user's usage data within 30 days — the chart totals keep them for the periods they were active, but they vanish from the detail table. A per-user report you pulled in March and pull again in June will not agree, and neither pull is wrong. The same page is where the "Last Activity Date" gotcha lives too: it is the most recent intentional activity in that app regardless of the period you asked for. It is not a value from inside your window.

None of this needs a data warehouse. It needs the same handful of endpoints read on a schedule and kept, which is what GraphPaaS does per tenant: the periods the Reports API already offers, plus its own dated snapshots for the numbers Microsoft hands over without a date. The value isn't the chart. It's that the question "when did this start?" has an answer at all.