Intune reporting looks like one surface and behaves like four. A number in the admin centre can be a live read of the service, a cached result nobody has regenerated for three days, or a thirty day trend that will never contain this morning. The reports do not label which is which in any consistent way, so the common failure is not a wrong number. It is a correct number read as though it were current. This is the reporting half of Intune troubleshooting when the number is the suspect, and it is where most disputed tickets actually start.
What Intune reporting is made of
Microsoft groups the reports into four focus areas. The grouping is worth reading before any individual report, because it states what each one was built to do, and therefore how current it is entitled to be. The categories and their descriptions are set out in the Microsoft Intune reports reference.
| Focus area | What Microsoft states it provides | What that means for freshness |
|---|---|---|
| Operational | Timely, targeted data that helps you focus and take action | The closest thing to a live view, and the only category built for triage |
| Organizational | A broader summary of an overall view, such as device management state | Aggregated. Built for a management summary, not for proving one device changed |
| Historical | Patterns and trends over a period of time | Windowed. A trend cannot answer a question about one device this hour |
| Specialist | Raw data so you can create your own custom reports | An export route. Freshness is whatever your own pipeline gives it |
Two reports with similar names can sit in different categories, which is why a compliance figure on one blade disagrees with a compliance figure on another and both are correct. Device compliance trends is the clearest example. It is a historical report over a thirty day window, and Microsoft also describes its data as a snapshot of the current tenant state, near real-time. Both statements are true of different parts of the same tile, and a reader skimming for a number will take one and not the other.
The three delays behind every Intune reporting number
There is no single Intune reporting lag. There are three, and they stack.
The first is the client check-in. A device reports state when it checks in, and nothing done in the console changes what the device has not yet sent. For newly enrolled devices, Microsoft publishes these estimated refresh cycles in the policies and profiles questions reference:
| Platform | Estimated refresh cycle after enrolment |
|---|---|
| Windows | Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then around every 8 hours |
| Android, AOSP | Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then around every 8 hours |
| iOS/iPadOS | Every 15 minutes for 1 hour, then around every 8 hours |
| macOS | Every 15 minutes for 1 hour, then around every 8 hours |
After that opening burst the steady state is about every 8 hours on every platform. There is a second constraint in the same article that is easier to miss and explains more arguments: independent of the client schedule, devices are only allowed one maintenance sync every 6.5 hours. A user pressing Sync in Company Portal four times in a row is not going to move that, and the pattern of a forced Intune sync that appears to do nothing is usually this limit rather than a broken client.
The second delay is the service side. Once the device has reported, Microsoft states plainly that it can take more time for Intune reports to reflect the latest status of the policy on the device in the portal. No figure is attached to that sentence anywhere in the documentation. That absence is itself the useful fact: if a report disagrees with a device for an hour, there is no documented basis on which to call it a fault, and raising a ticket at that point will be closed as by design.
The third delay is the report itself, and it is the one most often blamed on the other two. Several Intune reporting surfaces do not refresh on a timer at all.
Generated on demand, and the timestamp that settles the argument
The Device compliance report at Reports > Device compliance > Reports carries a Generate report button and, more usefully, a time stamp of when the report was last generated. Read the timestamp before reading the numbers. Nothing else in the interface tells you how old the data is, and the figures render identically whether they were produced a minute ago or last Thursday.
Device assignment status behaves more aggressively still. It returns empty until you generate it, and once generated, Microsoft states the reporting data are available for up to three days before needing to be generated again. A three day old cached result, drawn in exactly the same visual style as a live one, is the most reliable way in the product to be confidently wrong about an assignment.
Windows feature update reports will show nothing at all until data collection for them has been configured. An empty report there describes your configuration, not your estate.
The retention windows, and what quietly falls off
Four windows in Intune reporting are worth writing down somewhere a colleague will find them, because each one silently caps an investigation.
| Report | Stated window | What it costs you |
|---|---|---|
| Device actions | Data for the past 180 days | Who wiped a device in the previous financial year is not answerable here |
| Windows Autopilot deployments | Deployment details for the last 30 days | A quarterly deployment review has to be assembled as it happens, not afterwards |
| Device compliance trends | A 30 day trend | No view of a compliance regression that began last quarter |
| Device assignment status | Up to three days before regeneration | Silent staleness rather than an empty report |
None of these is a problem until something outside the window is asked for, at which point it is not a reporting problem any more, it is a records problem. If an audit, a security review or a licence true-up will ever need a date older than the shortest window above, the export has to be scheduled before the question is asked. That is what the Specialist category exists for, and the reason the Intune Advanced Analytics licence question comes up at exactly this point in most estates.
The failure modes
These are the Intune reporting behaviours that read as bugs and are in fact documented behaviour.
- A policy reports Succeeded and the device does not have the setting. Succeeded means the device acknowledged the policy at its last check-in, not that the setting survived. A later policy can overwrite it, which is a different investigation: see which policy actually wins in an Intune policy conflict.
- Two blades disagree about the same compliance number. Expected when one is operational and the other historical or on demand. Compare timestamps first, categories second, and only then suspect the data.
- One device appears several times in Noncompliant devices and settings. Documented: a device that is noncompliant with four different settings is in the list four times, once for each setting. The report counts settings, not devices, so a device count taken from its row total will be wrong.
- A bulk action silently covers part of the selection. Bulk actions take up to 100 devices at a time. On a larger set the action is not partially failing, it is partially selected.
- App install figures lag an obviously finished install. App Install Status at Apps > Monitor is still bound by the same check-in cadence, which is worth remembering before re-packaging anything during an Intune Win32 app deployment that reports the wrong state.
- A Log Analytics feed stops without an error. Each resource can have up to five diagnostic settings, and a single diagnostic setting can define one of each destination. Adding a sixth does not warn you into the right shape.
What I would do differently
I have not run any of this against a production fleet. My tenant is a lab with no enrolled devices, so every figure above is Microsoft’s, read today, rather than a measurement of mine. What the documentation does support is a working rule, and it is the one I would give a service desk.
Treat every number in Intune reporting as evidence with a timestamp attached, and refuse to act on one that does not have a visible timestamp or a known cadence. Before escalating any disagreement between a report and a device, check three things in order: when the device last checked in, when the report was last generated, and which of the four focus areas the report belongs to. If all three are unremarkable and the gap is under eight hours, there is nothing to escalate yet, because Microsoft has not committed to a figure you could hold it to.
The second habit is less obvious. Decide which reports you will export on a schedule before you need them, not after, because three of the four windows above are shorter than a normal audit cycle. The retention is not a defect, it is a design decision, and it is only expensive for the organisation that discovers it retrospectively.
Last verified: 17 October 2026.
