Why does multitenant advanced hunting return less data than the per-tenant portal?

Reviewed by ContraForce team · Updated 2026-09-04

> Multitenant advanced hunting caps its total result set at 50,000 records, with each tenant capped at 50,000 divided by the number of tenants queried. A hunt across fifty tenants returns at most 1,000 rows per tenant regardless of how many matched, while the same query in a single tenant returns up to 100,000.

What is the documented cap?

Microsoft documents two different ceilings for the same query language, and the difference is easy to miss because both are called advanced hunting.

Run in a single tenant, a query may return up to 100,000 rows, execute for up to 10 minutes, and produce a result up to 64 MB.

Run through multitenant management, the total result set is capped at 50,000 records, and Microsoft states that "the result set from each individual tenant is capped at 50,000 divided by the number of tenants queried."

Why does this look like missing tenants rather than truncation?

Because truncation is silent and unevenly distributed. A tenant with few matching records returns all of them and looks complete. A tenant with many returns its share of the divided budget and looks like it has less activity than it does. A tenant whose matches fall outside whatever ordering the truncation applies can return nothing at all and appear absent.

Nothing in the result signals which tenants were truncated. The absence of an error is not evidence of completeness, which is why the failure mode reads as configuration doubt rather than as a quota.

There is a second, unrelated ceiling worth knowing. Advanced hunting CPU resources are allocated per tenant based on tenant size, the portal warns above 10 percent consumption, and queries are blocked once a tenant reaches 100 percent until after the next 15-minute cycle. A scheduled cross-tenant hunt that runs hot can be throttled rather than truncated, which produces a different partial result for the same query on a different day.

How do you check coverage yourself?

Count what each tenant returned and compare it to the per-tenant budget. If any tenant is sitting exactly on the cap, that tenant is truncated and the real number is unknown.

```kusto // Run through multitenant advanced hunting. // Any tenant whose count equals the per-tenant budget is truncated. DeviceInfo | where Timestamp > ago(24h) | summarize Records = count() by TenantId | extend PerTenantBudget = toint(50000 / toscalar( DeviceInfo | where Timestamp > ago(24h) | summarize dcount(TenantId))) | extend Truncated = Records >= PerTenantBudget | order by Truncated desc, Records desc ```

Two practical rules follow. Query fewer tenants per run and page through the estate, which raises the per-tenant budget proportionally. And filter hard in the query rather than in the result, since the cap applies to what is returned, not to what matched.

How do you get cross-tenant visibility that does not divide?

The cap is a property of fanning one query across many tenants and merging the results at query time. An operating layer that maintains its own incident record per customer is not subject to it, because the cross-tenant view is not a federated query.

ContraForce holds the incident records, verdicts, and evidence its agents produce in its own regional deployment, while customer logs and telemetry stay in the customer's own SIEM or XDR under their retention settings. Cross-customer reporting reads the platform's own records rather than fanning a query across every tenant, so the answer does not shrink as the book of customers grows.

Sources

• Multitenant advanced hunting
• Advanced hunting overview, quotas and usage parameters
• Microsoft Defender multitenant management requirements