Catch critical issues early. Ignore the noise automatically
Set threshold and baseline rules on any signal, group issues into incidents, and send each new incident to Slack, PagerDuty, email and more.
Build a rule. See it fire.
Set a fixed threshold or a baseline, then watch the verdict change.
Five issues. How many pages?
The policy decides how issues group into incidents. A page goes out only when an incident opens.
- Rule AWeb Response Time > 2 s · App-1
- Rule AWeb Response Time > 2 s · App-2
- Rule AWeb Response Time > 2 s · App-3
- Rule BError Rate > 5% · App-1
- Rule BError Rate > 5% · App-2
Waiting for the first issue…
One incident. Every channel.
Pick a channel to see how the incident reaches it, then send a test.
- Policy
- Production Health
- Incident
- #418
Every channel attached to the policy gets each new incident. Layout shown is a sample.
Alert events
- Incident AcknowledgedAcknowledged by Sarah
- NotificationSent to PagerDuty
- NotificationSent to Slack
- Issue OpenedWeb Response Time exceeded 2s on checkout-service
Quiet when planned.
Rules keep evaluating. Notifications inside the window are silenced.
isRecurring: true · duration: 2 hours · recurrence: every 1 week on Sun · starts 02:00
- Disk I/O above 90% on db-backup-1Issue opened · rule kept evaluatingNotification silenced
- Host not reporting: db-backup-1Issue opened · rule kept evaluatingNotification silenced
- Web Response Time above 2 s on checkout-serviceIssue opened · rule kept evaluatingNotification sent
- CPU Used above 90% on app-prod-1Issue opened · rule kept evaluatingNotification sent
- Error Rate above 5% on payment-serviceIssue opened · rule kept evaluatingNotification sent
- 2 silenced · 3 sent · sample data
Alerting, screen by screen.
Real screens from the Atatus app.
Questions teams ask before switching alerting platforms
Pricing, deployment, data and the agent. If something is missing, a person will answer it on a demo call.
With settings on each alert policy. Issues are grouped into incidents by policy, by rule, or by rule and target, and a notification goes out only when an incident is created. A repeat on the same rule and target updates the open incident instead of opening a new one. Warning and critical thresholds separate early signals from urgent ones, durations and the all or any time function filter out brief spikes, and maintenance windows silence notifications during planned work.
Atatus correlates alert issues into Problems. Issues that happen in the same window on connected services, or on the same host, pod or workload, become one Problem with each issue tagged as root cause or symptom. From a Problem you can run AI Analysis, which looks across logs, metrics and traces for the cause.
Yes. Atatus has 26 notification channels: email, Slack, Microsoft Teams, Google Chat, Twilio SMS and other chat tools; PagerDuty, OpsGenie, VictorOps, BigPanda and Datadog for incident management; Jira, ServiceNow, GitHub, GitLab, Linear and other issue trackers; and webhooks. Every channel attached to a policy gets each new incident, and you can send a test notification to check a channel.
Yes. Threshold rules compare a metric above, below or equal to a value, with an optional warning level, over 5, 10, 15, 30 or 60 minutes. Baseline rules for APM and Browser metrics fire when a metric moves a set percentage away from its moving average, so you don't need a fixed number. SLO alerts watch error budget burn rate and the share of budget consumed. Rules cover Browser, APM, Infrastructure, Kubernetes, Logs, Analytics and more.
Create a policy, add rules and attach a channel. The docs suggest five starter alerts: web response time above 2 seconds for 5 minutes, error rate above 5% for 5 minutes, host not reporting for 5 minutes, CPU above 90% for 15 minutes, and browser page load time above 5 seconds for 10 minutes.