Managing repeated alerts

In Kaseya MDR, alerts surface security‑relevant activity that may require investigation or response. In some cases, alerts are valid but appear repeatedly due to expected behavior, scheduled activity, or overlapping evaluation across multiple security products.

Repeated alerts do not always indicate risk, but they should always be investigated before suppression or tuning decisions are made.

If you are unsure whether a repeated alert represents risk, expected behavior, or duplication across products, start with Working with alerts to review severity and initial context before continuing here.

This article explains how to manage repeated alerts in context, starting from a real alert and using investigation findings to decide when suppression is appropriate versus when other noise‑reduction options should be used.

This article focuses on investigation‑first decision‑making and workflow. It does not document suppression rule creation steps. For full suppression mechanics and configuration, see Alert suppression.

How alert behavior decisions fit together

Use the articles in this section together as a deliberate decision ladder:

1. Start with the alert

   Review the alert and understand what it represents before taking action.

   See Working with alerts

2. Investigate before changing behavior

   Use the Analysis page to validate context, scope, and impact.

   See Investigating activity using the Analysis page

3. Decide how (or whether) alert behavior should change

   Determine whether tuning, suppression, or no action is appropriate based on investigation results.

   See Managing noise and signal; Managing repeated alerts

4. Apply the selected change in the correct place

   Severity or detection tuning > global prioritization changes.
   See: Managing alert severity and detection tuning

   Suppression rules > scoped exceptions for specific conditions.
   See Suppressing alerts from Events; Alert suppression

Each article in this set is intentionally scoped to one step in this process.

Avoid skipping steps. Changing alert behavior without investigation can hide meaningful security activity and reduce confidence in response decisions

Scenario: You are seeing the same alert repeatedly

You might encounter repeated alerts when:

• A scheduled or automated process runs regularly

• Administrative activity occurs during maintenance windows

• A known integration or service account performs routine actions

• A specific user or location generates expected activity

• Similar alerts appear in more than one product because the same activity is evaluated by multiple detection engines

Repeated alerts do not always indicate risk—but they should be reviewed before being suppressed.

Step 1: Review the alert and investigate context

Before suppressing an alert, confirm that the behavior is expected.

1. Open the alert from the Events view

2. Review the alert details and triggering conditions

3. Open the Analysis page to investigate related activity

4. Validate that:

   • The activity matches a known pattern

   • There is no associated suspicious behavior

   • The scope of the activity is well understood

If the alert represents a real security risk, suppression is not appropriate. If investigation confirms the alert is valid but repeatedly triggered by expected behavior, continue to Step 2 to choose a noise‑reduction approach.

Step 2: Decide how to reduce the noise

Once you have validated that the activity is expected, choose the least disruptive option to reduce alert noise:

Option A: Adjust alert severity or detection tuning

Use severity tuning when:

• The alert is valid but consistently low urgency

• You still want visibility without repeated escalation

Severity tuning affects future alerts globally and does not suppress data collection. For how to adjust severity or detection logic, see Managing noise and signal.

Option B: Suppress the alert under specific conditions

Use suppression when:

• The activity is expected only in a specific context

• The alert is still valuable in other scenarios

• You can clearly define when suppression should apply

Suppression is best suited for scoped exceptions, not global changes. This article does not create suppression rules. If suppression is appropriate, start from a real alert or investigation context using Suppressing alerts from Events (investigation-based suppression).

For full behavior, scope, and configuration details, see Alert suppression.

If repeated alerts do not change investigation outcomes or response decisions, reducing escalation may be appropriate. If they do change decisions, suppression should not be used.

IMPORTANT  Suppressing an alert in Kaseya MDR affects only MDR‑based escalation and visibility. It does not disable alerting, detection, or response behavior in SaaS Alerts or Kaseya SIEM. If similar alerts originate from other products, review suppression and tuning options in those products separately.

When not to suppress

Do not suppress alerts when:

• The behavior has not been fully investigated.

• The activity is suspicious or unclear.

• The alert represents a newly observed pattern.

• Suppression would hide activity needed for compliance or audit.

In these cases, continue investigating or escalate appropriately.

Best practices for scenario‑based suppression

• Always investigate at least one representative alert

• Prefer temporary, date‑based suppressions when possible

• Scope suppressions as narrowly as possible

• Document the reason for suppression clearly

• Review suppression rules periodically

After any noise‑reduction change, return to the Analysis page to confirm that visibility is preserved and no unintended blind spots were introduced.

Related articles

• Alert suppression: Learn how suppression works in Kaseya MDR, when to use it, and how to configure scoped rules without disabling investigation visibility

• Managing noise and signal: Decide when and how alert behavior should change after investigation, including severity tuning and noise‑reduction strategies that preserve investigative context