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:
| Status | Description |
|---|---|
| Opened | Threshold breached, incident created, notification sent |
| Acknowledged | A team member acknowledged the incident (prevents repeated notifications) |
| Closed | Condition resolved automatically, or manually closed by a user |
- 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:
| Issues generated | Incidents created | |
|---|---|---|
| Rule A triggers on App-1, App-2, App-3 | 3 issues | 1 incident total |
| Rule B triggers on App-1, App-2 | 2 issues | (same incident) |
| Total | 5 issues | 1 incident |
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:
| Issues generated | Incidents created | |
|---|---|---|
| Rule A triggers on App-1, App-2, App-3 | 3 issues | 1 incident for Rule A |
| Rule B triggers on App-1, App-2 | 2 issues | 1 incident for Rule B |
| Total | 5 issues | 2 incidents |
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:
| Issues generated | Incidents created | |
|---|---|---|
| Rule A triggers on App-1 | 1 issue | 1 incident (Rule A + App-1) |
| Rule A triggers on App-2 | 1 issue | 1 incident (Rule A + App-2) |
| Rule A triggers on App-3 | 1 issue | 1 incident (Rule A + App-3) |
| Rule B triggers on App-1 | 1 issue | 1 incident (Rule B + App-1) |
| Rule B triggers on App-2 | 1 issue | 1 incident (Rule B + App-2) |
| Total | 5 issues | 5 incidents |
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
| Preference | Incidents created | Notifications | Best when |
|---|---|---|---|
| By Policy | Fewest (1 per policy) | Least noisy | You have simple policies with few rules |
| By Rule | Moderate (1 per rule) | Balanced | You want to separate different problem types |
| By Rule and Target | Most (1 per rule + target) | Most granular | You run multiple services and need per-target tracking |
Tip: Start with By Rule for a good balance between signal and noise. Switch to By Rule and Target when you need to track which specific application or host is affected.
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 — this 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.
+1-415-800-4104