Why does multitenant advanced hunting return less data than the per-tenant portal?
The 50,000-record cap divided by tenant count, why truncation reads as missing tenants, and how to check coverage.
Reviewed by ContraForce team · Last verified
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.
Last verified: 2026-09-04. Sources linked at the foot of the page.
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."
| Tenants queried | Maximum rows per tenant | Total |
|---|---|---|
| 1 | 50,000 | 50,000 |
| 10 | 5,000 | 50,000 |
| 50 | 1,000 | 50,000 |
| 100 | 500 | 50,000 |
The ceiling tightens as a provider grows. A book of customers that doubles halves the visibility any single cross-tenant hunt gives into each one.
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.
// 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
Verified on the date shown. Microsoft raises quotas without announcement; confirm the current figures before sizing a hunting strategy around them.
Continue the evaluation
Sources and review method
Product capabilities were reviewed against the page-specific primary sources below on 2026-10-09. Performance claims require the population and limitations stated in the linked methodology.
- NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations (verified 2026-10-09)
- ContraForce measurement methodology (verified 2026-10-09)
Related guides on Microsoft security operations
- Is there an API for Microsoft Defender multitenant management?, The three documented Defender XDR APIs, and what multi-tenant operations have no programmatic path.
- Can Security Copilot agents run across Lighthouse-connected tenants?, Workspace and capacity boundaries that make AI capability per tenant rather than per provider.
- Browse all answers
- See how the ContraForce platform works
Ready to Transform Your Security Operations?
See how ContraForce runs the full delivery loop for service providers. Connect a supported tenant and validate the workflow in your own environment.
No credit card. Connect one workspace: scoped Entra ID application consent, no endpoint agents, no log forwarding.