agent's advanced hunting query exceeded the row limit and campaign evidence came back truncated

TL;DR

Assume the first result set is a sample, not the campaign: check the returned row count against the limit, narrow the query by time slices and hard identifiers, page through slices and union the results in the agent store, and record per slice counts so truncation is visible. Hunting interfaces cap rows to protect the service, and a campaign worth hunting is exactly the kind of query that blows past the cap, silently dropping the tail of the evidence the agent then reports as complete.

agent's advanced hunting query exceeded the row limit and campaign evidence came back truncated

Use this when

• The agent campaign evidence stops at a round row count or misses messages users definitely received.
• Rerunning the same hunting query returns slightly different members.
• The campaign spans days, many recipients, or several sender variants.

Not for this skill when

• The query returns an error, not results. Fix the KQL or the permissions first.
• The campaign is small and results fit comfortably in one page. Truncation is not your problem there.

Steps

1. Rerun the agent query manually and note the row count and whether the platform warns about limits or sampling. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the limit affecting the query is confirmed with its value
2. Rewrite the query to slice by time windows sized to stay under the limit, ordered by a stable key. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: each slice returns comfortably under the cap in test runs
3. Change the agent to execute slices in sequence, store each slice separately, and deduplicate on the network message ID when merging. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: a test campaign merges slices with no duplicate messages in the result
4. Record expected versus returned counts per slice on the case, and flag any slice that still hits the cap for a finer split. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the case shows per slice counts and any capped slice is flagged
5. Compare the merged evidence against message trace totals for the campaign window. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: merged counts reconcile with trace totals within an explained difference

Why it happens

Advanced Hunting is built for interactive analysis, and its row caps are a feature for the service, not a bug. Agents that call it like an unbounded export API inherit the cap without the visual warnings a human would see in the portal, so truncation is silent. Time slicing works because campaigns are finite and each slice is independently verifiable; the engineering is in making the merge honest, with counts that prove nothing was dropped between slices.

Variants and edge cases

agent advanced hunting query exceeded row limit evidence truncated

The exact cap and truncation wording.

kql hunting query row limit paging time slice campaign export

The paging technique variant.

defender hunting results incomplete campaign too many rows agent

The incomplete evidence symptom variant.

Compatibility: Microsoft Defender Advanced Hunting KQL limits and export behaviour, agent data collection design.

Edge cases to check:

• Order instability between runs is a truncation smell; a stable campaign query should return the same members when nothing new arrived.
• Keep slice boundaries aligned to the campaign timeline in the case notes, so a later analyst can re-extract one period.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e3WHKqYCGk-FeeRcDSkuTQ