Alert Incidents

An alert policy can have multiple rules. When any rule’s threshold is breached, Atatus creates or updates an incident, a container that groups one or more related issues together. How issues are grouped into incidents depends on the incident preference you choose when creating the alert policy. Atatus notifies you through the configured notification channels when a new incident is created, not every time an existing incident is updated with additional issues.

​

Incident lifecycle

Every incident moves through these states:

• An incident is automatically closed when the condition that triggered it returns to normal (metric drops back below the threshold for the evaluation window).
• You can also manually close an incident from the Alerting page or via the API.
• Acknowledging an incident signals your team is aware of the issue. An acknowledged incident remains open until the condition resolves or it is manually closed.

​

Incident preferences

When creating an alert policy, you choose one of three incident preferences. This controls how many incidents are created and how issues are grouped.

​

By Policy

One incident is created per policy, regardless of how many rules or targets are violated. How it works: All issues from all rules in the policy are grouped into a single incident. A new incident is only created after the previous one is closed. Example: You have a policy “Production Health” with two rules:

• Rule A: Web Response Time > 2 seconds
• Rule B: Error Rate > 5%

Both rules trigger at the same time across 3 applications (App-1, App-2, App-3). Result: Best for: Simple monitoring setups where you want minimal notifications and a single view of all problems in a policy.

---

​

By Rule

One incident is created per rule, regardless of how many targets are violated by that rule. How it works: Issues from the same rule are grouped into one incident. Different rules create separate incidents. Example: Same policy “Production Health” with the same two rules triggering: Best for: Distinguishing between different types of problems (latency vs errors) while keeping noise manageable.

---

​

By Rule and Target

One incident is created per rule-and-target combination. This is the most granular option. How it works: Each target (application, host, or entity) that violates a rule gets its own incident. Issues are not grouped across targets. Example: Same policy “Production Health” with the same two rules triggering: Best for: Multi-service or multi-host environments where you need to track each affected target independently. Gives you per-target incident history and per-target notifications.

​

Choosing the right preference

​

Viewing incidents

Navigate to Alerting > Incidents to see all incidents. You can filter by:

• Status: Open, Acknowledged, or Closed
• Time range: View incidents from a specific period
• Policy: Filter by alert policy
• Search: Search by incident description or policy name

Each incident shows:

• Severity (Critical or Warning)
• Alert policy and rule that triggered it
• Affected target (application, host, or entity)
• Start time and duration
• Number of related issues

​

Managing incidents

​

Acknowledge an incident

Click Acknowledge on an open incident to indicate your team is investigating. This prevents repeated notifications for the same incident but keeps it open until the condition resolves.

​

Close an incident

Incidents are automatically closed when the triggering condition resolves (the metric returns to normal for the configured duration). You can also manually close an incident by clicking Close, which records who closed it and marks the closure as manual.

​

Incident deduplication

Atatus uses an incident signature (a hash of the policy, rule, and target) to prevent duplicate incidents. If a rule triggers again while an existing incident is still open for the same target, the existing incident is updated rather than creating a new one.