Alerts

​

How Alerts Work

Alerts represent events generated by your monitoring and operational tools when something needs attention—like a firing Datadog monitor, a PagerDuty incident, or a Zendesk ticket. In Rootly:

• Each alert has a status:
  • open
  • triggered
  • acknowledged
  • resolved
• Alerts can be linked to incidents, so responders see the right telemetry and tickets in context.
• Alert records track a request count and last received time, so you can see how often a condition has fired.

Examples include:

• A PagerDuty incident has been created
• A Datadog alert has been triggered
• A Zendesk ticket has been created

Alerts can be automatically ingested into Rootly and connected to incidents via workflows, mappings, or manual linking.

---

​

Supported Alert Sources

Rootly integrates with many alerting and ticketing tools. Some of the most common include: Additional alert sources include tools like Asana, ClickUp, Rollbar, Jira, Honeycomb, ServiceNow, Linear, Grafana, Alertmanager, Google Cloud, CloudWatch, Azure, Splunk, Chronosphere, New Relic, GitLab, and more—usually via a dedicated integration or generic webhooks. If your provider is not listed, Rootly can ingest alerts through:

• Generic Webhook Alert Sources

---

​

Alert Deduplication

Monitoring systems often keep sending alerts while a condition remains unhealthy. Instead of flooding responders with multiple identical alerts, Rootly provides two layers of deduplication:

1. Configurable per–Alert Source dedupe (by unique identifier)
2. Payload-based suppression (ignored duplicate requests)

Together, these keep your alert list clean while preserving a full history of how often a condition has fired.

---

​

1. Combining Alerts by Unique Identifier

At the Alert Source level, you can tell Rootly to combine duplicate alerts into one alert using a stable identifier from the payload or alert fields. To configure:

1. Open an Alert Source in Rootly Web.
2. Go to the Events tab.
3. Toggle on Combine duplicate alerts into one alert.
4. Choose where the identifier comes from:
   • Payload – use a JSONPath into the raw payload (recommended for most cases)
   • Alert field – use a specific alert attribute
5. Provide the deduplication key path (e.g., a JSONPath value).
6. Optionally apply a regular expression to normalize the value before matching.

If deduplication is enabled, Rootly requires a valid unique identifier; the UI will block saves until you configure one. When a new alert arrives:

• If its deduplication key matches an existing alert, Rootly:
  • Does not create a new alert
  • Adds a duplicate/ignored request event to the original alert
  • Increments the alert’s requests count
  • Updates last_request_at

This behavior shows up in the UI as:

• A badge like ×3 next to the alert
• A tooltip indicating how many matching requests have been received and when the last one arrived

---

​

2. Payload-Based Duplicate Suppression

In addition to key-based dedupe, Rootly can also suppress exact payload duplicates at the team level. When enabled, if Rootly sees another alert with the exact same request body as a previous “ignored” event for that alert:

• The request is counted against the same alert
• Rootly records an internal event (e.g., "ignored_alert_request")
• No new alert is created

---

​

Linking Alerts to Incidents

Alerts become most useful when tied directly to incidents. In Rootly, alerts can be associated with incidents via:

• Integration mappings and workflows
  • e.g., “When a PagerDuty incident is created, attach the alert to the corresponding Rootly incident.”
• Automation logic
  • e.g., based on service, environment, or alert attributes
• Manual linking from the incident or alert views

Once linked, responders can:

• Jump from the incident to the underlying alert(s)
• See how many times the alert fired (via the requests count)
• Use alert details to drive mitigation and follow-up tasks

---

​

Best Practices

• Choose a stable deduplication key
  Use identifiers like monitor IDs, incident keys, or ticket IDs—avoid full message text or highly variable fields.
• Start narrow, then broaden if needed
  Begin with conservative dedup rules and relax them as you gain confidence, to avoid accidentally merging unrelated alerts.
• Link alerts to incidents early
  Use workflows to automatically attach alerts to incidents as soon as they are ingested.
• Watch the request count
  A high ×N count on an alert is a strong signal of ongoing or flapping conditions and can inform severity and prioritization.
• Tune rate limits for noisy environments
  If you know a source can spike, consider increasing the per-source rate limit for that team.

---

​

Troubleshooting