The Queue

Introduction

An endpoint alert is not a task. It is a piece of evidence that the platform will try to attach to other pieces of evidence, and what arrives in front of an analyst is the result of that attempt rather than the alert itself.

Understanding that sequence is what separates working a queue from being worked by one. Between the detection firing and a human seeing anything, four things happen: correlation, prioritization, tuning, and assignment. Each was configured by somebody, three of them are adjustable, and all four decide what you spend your day on.

You will finish able to say why a given item is at the top of your queue, why another one never appeared, and which of the two is the more expensive question.

An alert says one thing happened on one asset. An incident is the platform's assertion that several such things belong together, built by correlating alerts across endpoints, identities, mail and applications into a single attack story.

The cross-workload part is the reason this matters more than it would in an endpoint-only tool. An endpoint alert about a suspicious child process is one thing; the same alert correlated with a mail alert about the attachment that started it and an identity alert about the sign-in that followed is an intrusion with a beginning and a direction. None of that correlation is available to a fragment that was suppressed before it reached the engine.

That distinction has a practical consequence that catches new analysts. Triaging alerts individually means repeatedly asking whether one fragment is worrying, which is a question fragments cannot answer. The same fragment inside an incident with three others is frequently obvious in either direction.

Work the incident queue rather than the alert queue for that reason, and drop to the alert view only when an incident needs breaking apart. The exception is tuning work, which is done from the alert view by definition, because a tuning rule is a statement about an alert type rather than about an incident. The alert queue is a diagnostic tool for understanding what your detections produce; it is a poor place to decide what is happening, because it asks you to assess evidence with its context removed.

Correlation does not stop once an incident exists. Where two incidents turn out to be the same activity the platform merges them, moving the alerts and tags to one side and leaving a redirect behind on the other.

The platform also keeps correlating after an incident exists. Where two incidents turn out to be the same activity it merges them, moving the alerts and tags to the target and leaving a redirect behind on the source. The direction of that merge is chosen by the platform rather than by you, even when you trigger it manually, which means an incident you were working can become a redirect while you have it open. Recognizing that is worth more than resisting it: the work is not lost, it has moved.

There is one thing you control that affects this, and it is not the merge. Correlation works from the entities an alert carries, so a custom detection that emits a device and an account is joinable and one that emits a bare string is not. That is a detection engineering decision taken in EO3 whose entire consequence lands here, in whether your own rules can participate in an attack story or only ever appear alone.

Classification also interacts with merging. Two incidents carrying different classifications or determinations do not combine cleanly, so closing an incident with a hasty verdict can affect what happens to it when related activity appears a week later.

Read the order rather than the boxes. Tuning happens before correlation, so a suppression decision reaches further than a queue entry. It decides whether that evidence is available to be joined to anything else at all.

The incident queue is ordered by a score rather than by arrival time. Threat context, the attack techniques involved, how critical the asset is and how rare the signal is all feed it, and the highest-scoring incidents surface at the top automatically.

That is a genuine improvement over a chronological list and it introduces a failure mode worth knowing about. A queue you work top-down is a queue whose bottom you never reach, and the bottom is now defined by a model rather than by the clock. Nothing ages into view.

The counter is cheap and almost nobody does it: sample the bottom. Take five incidents a week from the lowest-scoring end, work them properly, and record what you find. If the answer is consistently nothing, the scoring is working and you have evidence for it. If it is not, you have found the thing that a top-down queue is structurally unable to show you.

Published analysis of alert data gives that habit its weight. Roughly one to two per cent of confirmed incidents began life as an alert first labeled low or informational, which is small as a proportion and substantial as a count on any estate raising tens of thousands of alerts a year. Low severity means the detection was not confident, not that the activity was harmless, and those are very different claims.

Asset criticality is worth checking rather than assuming, because it is one of the inputs and it depends on the platform knowing which of your assets matter. On an estate where nobody has told it, that input contributes little and the scoring leans harder on the others.

Marking the assets that matter is therefore a small piece of work with a direct effect on the order of your own queue, and it is one of the few places where an operator can improve prioritization without touching a detection.

// What the queue is made of: alert titles by volume and severity
AlertInfo
| where Timestamp > ago(90d)
| where ServiceSource == "Microsoft Defender for Endpoint"
| summarize Alerts = count() by Title, Severity
| sort by Alerts desc
| take 25

The top five rows of that are almost always where your team's time goes, and they are the right place to start any tuning conversation. The rows at the bottom are worth a second look for a different reason: an alert title that has fired twice in ninety days is either a rare and valuable detection or a broken one, and the two are indistinguishable from the count alone.

Add severity to the grouping rather than filtering by it, which is what the query above does. Run it again scoped to a single device group when something looks odd. A title that dominates the estate-wide count and comes almost entirely from one group is a local condition rather than a detection problem, and the fix is on those machines rather than in the rule.

Grouping shows you the distribution: an alert title that arrives almost entirely at one severity is behaving consistently, and one spread across three is either detecting several different things under one name or is being scored on context that varies. The second is worth understanding before you tune it, because a rule written against the noisy half will suppress the useful half too.

Industry figures put roughly forty-six per cent of alerts across organizations as false positives, which is the context for everything in this section. That number is not an argument for suppressing half the queue; it is the reason tuning exists as a first-class feature rather than as a workaround, and the reason the difference between tuning and filtering is worth being precise about.

Tuning lets you hide or automatically resolve alerts when expected behavior in your organization matches conditions you define. Built-in rules ship for common benign activity, and you can write your own against evidence: files, processes, scheduled tasks and similar.

The vendor's own guidance is narrower than most teams read it as. It is for known internal business applications and security tests that produce expected activity, rather than as a general way to reduce volume. That distinction is the whole of the difference between the rules that are defensible and the rules that are not.

Coverage of tuning has also been expanding rather than static. Endpoint tuning rules reached general availability in May 2026, after the mail rules earlier in the year, and more workloads have been added since. That matters operationally for one reason: a built-in rule list you read a year ago is not the list you have now, so the periodic review below is a real task rather than a formality.

Two properties of suppression are worth knowing before you write one. Hiding an alert can remove it from incident correlation as well as from the queue, so the evidence stops being available to build a story from, though the underlying telemetry remains queryable for hunting. And an alert that is tuned out is not entirely abandoned: automated investigation continues in the background, and where it finds elevated risk the alert can be reopened and returned to the queue.

Those two pull in opposite directions and both are true, which is why the choice between hiding and resolving matters. Hiding removes the item; resolving marks it as a benign true positive and keeps it in the record as something that happened and was judged. For anything you expect to recur and want to be able to count later, resolving is the better instrument, and the count is what lets you revisit the decision with evidence.

There is a third option that is frequently the right one and gets forgotten because it is not on the tuning page: fix the thing generating the alert. A backup agent that trips a credential-access detection every night is a tuning candidate, and it is also a configuration somebody could change. Suppression is the correct answer when the behavior is legitimate and unchangeable; when it is legitimate and changeable, suppressing it is the cheaper answer today and the more expensive one over three years.

The background investigation is a genuine safety net and it is a net rather than a floor. It reopens what it finds risky, which means the alerts it does not reopen are ones an automated process judged uninteresting, and that is a different standard from a person having looked. Treat it as reducing the cost of a suppression mistake rather than eliminating it.

Build a rule from a specific alert rather than from the settings page where you can. A rule created from an alert you actually observed inherits that alert's evidence as its conditions, which keeps it scoped to the pattern in front of you instead of a guess about what else might resemble it.

Write the reason into the rule name while you are there. A rule called after the application and the ticket that prompted it is one somebody can evaluate in two years; a rule called after the noise it removes tells a future reader only that somebody found something annoying. Half the problem with inherited tuning is not the conditions, it is that nobody can reconstruct why.

Almost nobody arrives at a job with no tuning in place. What you inherit is a set of decisions taken by people under pressure, most of which were reasonable when they were made, and some of which have outlived their reason.

Give yourself an hour for it rather than treating it as a five-minute glance. Six rules with their conditions, authors, dates and suppression counts read carefully is an hour, and it is the single highest-value hour available to somebody new to an estate.

Read them in creation order rather than by volume. The sequence tells you the story of what the team found painful and when, and a run of rules created in one month is usually a response to a single event that nobody has revisited since.

Check the author column against your current staff list at the same time. A rule whose author has left is a rule with no owner, and the reason it exists left with them; it is not automatically wrong, and it is automatically undefended, which is a different problem and the easier one to act on.

Volume is not what makes a rule wrong, which is the point most easily missed in that exercise. The best-written rule there suppressed over five thousand alerts, and the worst one is defensible only as a decision to stop looking.

The other thing to take from it is that two of the six are fine, and saying so is part of the job. A review that returns six findings from six rules has not been read carefully, and it will be received as an attack on the people who wrote them rather than as an assessment. Naming the good rules is what makes the bad ones land, and in that artifact the best-written rule is also one of the highest-volume ones.

Notice also how the two defensible rules are constructed. Both name a specific signed executable, in a specific location, scoped to a device group rather than the estate, and both resolve rather than hide. That is four decisions each, and the four together are what make the rules explainable to somebody who was not there.

Use those four as the template for anything you write. Name the process, name the path, scope to the smallest population that covers the case, and resolve rather than hide unless you have a reason. A rule that cannot be written that way is usually a rule that should not be written at all, and noticing that at the point of writing is far cheaper than noticing it in a review two years later.

The last stage is a person picking the item up, and it is the only one of the four with no technical control behind it. An incident that scores highly, correlates perfectly and arrives at three in the morning is worked at eight, unless somebody is there.

That is worth establishing as a fact rather than assuming it from the rota. The measurement is simple and slightly uncomfortable: take the incidents from the last quarter, subtract creation time from first-touch time, and plot the result by hour of day.

The last line is the part that makes this an operations question rather than a complaint. Nobody decided to leave those hours uncovered; the rota was built for a working day and the estate kept generating alerts outside it, and the gap has never been stated as a number.

It connects directly back to EO0.2. A response role held by two people who work days is a capability the estate has during the day, and the incidents in that third row are the ones that arrive when neither of them is awake. The permissions question and the rota question are the same question asked from two ends.

Produce the number before proposing anything about it. A six-hour median outside working hours may be entirely acceptable to your organization, and it may not, and that is a decision for somebody other than you. What is not acceptable is nobody knowing.

Split it by severity as well when you present it. A six-hour median across everything is easy to dismiss; a six-hour median on the high-severity incidents specifically is a different conversation, and if the two numbers are similar that tells you the out-of-hours gap is indiscriminate rather than triaged.

Queue metrics are usually volume and time to close. Both are real and neither answers whether the queue is showing you your estate.

Neither number is good or bad by itself and both are diagnostic. A high suppression ratio in an estate with two carefully scoped rules is a noisy detection set. The same ratio across six rules written by four people over eighteen months is something else, and the second number tells you which you have.

Both are also defensible numbers to put in front of a manager, which matters more than it should. Queue volume and time to close reward suppression, because suppressing improves both; these two do not, and a team reporting all four is measuring the thing rather than the appearance of the thing.

There is a third figure worth having if your platform exposes it, which is how many suppressed alerts the background investigation reopened. A non-zero number is evidence that the safety net is doing something, and it is also a direct measure of how often your tuning was wrong in a way that mattered.

Record both numbers monthly rather than computing them once. The value is in the direction: a suppression ratio climbing while alerts per incident falls is a queue being tuned toward silence, and it is visible in a trend months before it is visible in an incident.

Everything above is about a queue somebody else shaped. This is how you read your own.

One last observation about the shape of this section. Of the four stages, you fully control one, can influence a second by improving what your detections emit, and control neither of the others. That ratio is normal for endpoint operations and it is not a complaint: the platform does the correlation and the scoring far better than a team could by hand. The obligation it creates is to be careful with the stage you do own, because it is the only one that can quietly starve the others.

The next section takes the four ways this work goes wrong, and organizes the rest of the course around preventing them.