Event Management
Event Management ingests events arriving from monitors and external tools, normalizes them, correlates them, and bundles them into a single case. It turns 20 notifications into one, triages them in the Triage Inbox, and then hands them to people.
What it does
It gathers in one place the events automatically created by monitors, Watchdog, and Error Tracking, together with events arriving from the Agent, more than 100 integrations, and any arbitrary source. Pipelines normalize the tags, pattern-based correlation and machine-learning correlation bundle related alerts into a single case, and the Triage Inbox assigns state and priority and sends notifications.
When to use it
Use it to resolve the situation where 20 notifications for the same outage arrive separately and nobody knows who is looking at what. Typical uses are bundling by service and environment tags, attaching deployment and configuration-change events as related information, and notifying Slack or PagerDuty about only the single bundled case.
An everyday analogy
It is the copy desk of a newspaper. From the pile of copy (events) arriving from each reporter, it bundles the copy about the same incident, writes a headline, and runs it as a single story on the page (the case). Its role is to keep one incident from filling the page as 20 scattered stories.
The Bottom Line - Not About Single Events, but a Mechanism for Bundling to Reduce Notifications
Event Management is a feature that ingests, normalizes, and correlates events from any source. Sources fall into three families: automatic generation by Datadog products, the Agent and integrations, and arbitrary sources such as third-party alerts and change requests (as of September 2026; source: Event Management). The breakdown of the three families, along with the definition of a single event, allotments, and billing, is left to the glossary entry on events; this article deals with the bundling side. The components are five: ingestion, the Triage Inbox, pipelines and processors, the Events Explorer, and correlation. Without it, if 20 monitors fire for one outage, 20 notifications go to different people and everyone investigates the same cause separately. With it, the 20 notifications become one case and a single notification.
The Ingestion Entry Points Are Standard Events and Arbitrary Sources
There are two entry points. One is standard events: events collected by the Agent and installed integrations come in automatically with no additional configuration. The other is ingestion from arbitrary sources, through which you can send in events such as third-party alerts and change requests (as of September 2026; source: Event Management). The precondition for correlation is deduplication: events are first deduplicated into alerts based on an aggregation key, and then correlated into cases according to your configuration. Events without an aggregation key are deduplicated into a single alert within a time window (source: Pattern-based Correlation). So even if the same monitor flaps and emits an event every 5 minutes, it counts as one alert as long as the aggregation key is the same; this stage sits before correlation.
| Source | Aggregation Key | What Happens Before Correlation |
|---|---|---|
| Events automatically generated by monitors | A key unique to each monitor ID and monitor group is attached | Flapping of the same monitor is deduplicated into one alert under the same key |
| Standard events from the Agent and integrations | Uses the sender's key, or one can be attached with the Aggregation Key processor in a pipeline | If there is a key, per key; if not, one alert within the time window |
| Ingestion from arbitrary sources | Attached at send time | After deduplication, correlated into cases according to configuration |
Aligning Tags with Pipelines and Processors
Because correlation bundles by tag, events will not bundle if the notation differs by source. That is where pipelines come in. They have three uses: enriching events by adding tags and custom attributes, remapping tags to standardize notation, and parsing messages and attributes with Grok rules to turn them into trackable tags (as of September 2026; source: Pipelines and Processors). The mechanism chains processors in sequence and passes events through them; an arriving event is matched against the filters of all pipelines, and the matching ones are applied. Filter conditions can use a query built in the Events Explorer as-is. How to write a Grok parser and how to design tags are left to their respective glossary entries, but in practice the order is to first align the service and env of events coming from external tools with Datadog's notation, and only then build correlation rules. If you build correlation before the notation is aligned, you end up trying to absorb the exceptions on the correlation side and it gets complicated.
Two Kinds of Correlation - Pattern-Based and Machine Learning
In the pattern-based method, the user decides how to bundle, and Datadog supplements it with related monitor events found by machine learning. In the machine-learning method, Datadog correlates automatically with no configuration, and you can optionally narrow only the scope (as of September 2026; source: Correlation Configuration). In pattern configuration, you select the event sources, specify events to exclude with a query, attach related events such as changes, and choose grouping tags from the facets. Related events are only attached to a case and do not create new cases. In the advanced settings, you set the minimum number of alerts required to create a case, the maximum time to keep adding new alerts to the same case, and the maximum time to keep reflecting state changes, and the title can be composed with a template such as {{tag.service}}. Recommended patterns based on the commonly used service and env tags are provided, and you confirm the results in a preview before saving the configuration (source: Pattern-based Correlation).
- An event arrives (monitor, integration, third-party tool)
- It is deduplicated by aggregation key into an alert
- It is correlated by a pattern (grouping tags + time window + minimum count) or by machine learning
- It is bundled into a single case, with related events (deployments and changes) attached
- The case priority is the highest among the bundled alerts; the state resolves automatically when all alerts recover
Triaging Bundled Cases in the Triage Inbox and Handing Them Off
The place to view bundled cases is the Triage Inbox. Selecting a project on the left shows the default views Open, In Progress, Closed, and Archived; you can switch between a split view suited to detailed investigation and a table view suited to bulk review, and sort by Priority, Created at, or Last Updated and save the result. You can change state, priority, and assignee directly on a card, and clicking the alert count lists the bundled alerts (as of September 2026; source: Triage Inbox). For cases created by correlation, the priority is the highest among the bundled alerts, the state is managed by the system and resolves automatically when all alerts recover, and the case reopens automatically if there is a recurrence within its time-to-live window. Unrelated alerts can be checked and removed, and removed alerts are not correlated again (source: Triage and Notify). The handling of assignees and states for cases themselves is the same as described in the Work Management guide.
| Action | What Happens |
|---|---|
| Tagging and commenting | Mention colleagues by name and leave a record on the case timeline |
| Sending notifications | Notify stakeholders via Slack, Microsoft Teams, email, or webhook |
| Escalation | Declare an incident in Incident Management, page the on-duty responder in On-Call, hand off to Workflow Automation or external tools |
| Sync with external tools | Synchronize records with Jira and ServiceNow |
| Root cause marker | Mark a related event such as a bad change as the root cause |
| Merging and splitting cases | Combine related cases into one, or split out alerts that need separate investigation |
Send Notifications and Tickets for the Single Bundled Case
The effect shows up in the number of notifications. The official documentation explains that instead of 20 notifications and 20 leads to investigate, you get one case and one notification (as of September 2026; source: Triage and Notify). There are two ways to send them. One is tickets: connecting ServiceNow and Jira in the project settings enables manual and automatic ticket creation and two-way synchronization. The other is view notifications, which notify you when a case matching a view that filters cases with a query is created. Destinations are PagerDuty, email, webhook, Microsoft Teams, and Slack. Unlike per-monitor notification settings, the key point is that the unit becomes the bundled case; the way to tame notifications that keep firing, described in the glossary entry on alerts, belongs to the monitor side, whereas this is a cross-monitor story. If your organization pages the on-duty responder through On-Call, deciding in advance which route is authoritative, escalation from the Inbox or view notifications sent to PagerDuty, prevents double paging.
How to Divide the Work with Monitor-Side Notification Measures
The means of reducing notifications fall into three layers, and Event Management is the middle one. The first layer is within a single monitor, tuning thresholds, evaluation windows, and renotification intervals; the problem of the same monitor flapping and firing repeatedly is solved here. The second layer is cross-monitor, bundling by service or env the problem of different monitors firing for the same root cause. The third layer is on the human side, deciding who receives the single bundled case through On-Call and Work Management. If the sender is a single monitor, it is the first layer; if it is multiple monitors or tools, it is the second. The order is the same: first tune the monitor side, and build correlation only when simultaneous firing still remains. Do it the other way around and you end up trying to absorb monitor flapping with correlation too, and the tuning of time windows and minimum counts never ends. If you count in the Explorer how many monitors fired for the same service in the same 10 minutes, the need for the second layer can be judged from measurement. Pricing is left to the billing section of the glossary entry on events, and the overall picture is covered in how to read the pricing.
Things to watch out for
- This article is based on the official documentation as of September 2026. Correlation configuration items and integration destinations may change, so when configuring, give priority to what the screen shows and the official documentation.
- The allotments and billing for Event Management are covered in the glossary entry on events, and this article does not show unit prices. Confirm contract terms with the public price list and your account contact.
- The state of cases created by correlation is managed by the system, and manual state changes are overwritten (as of September 2026). If you want to close a case by hand, confirm that the bundled alerts have recovered before doing so.