Event

Overview

An event is a signal that records something that happened at a particular time as a single item. Datadog automatically creates events from monitor state changes, Watchdog detections, and new errors found by Error Tracking, and the Agent and installed integrations also send occurrences such as container restarts and job completions. If you submit your own deployments and configuration changes, you can plant a marker of the change right above the moment a graph bends. It is the concept you care about when you want to narrow down the cause of an incident from "when what was changed," and when you want to gather human work and notifications from external systems into the monitoring interface.

Not a trend of points, but a single occurrence

An event is a signal that records something that happened at a particular time as a single item. Whereas a Metric lines up numeric values under the same name at equal intervals to show a trend, an event leaves a record of "when / what / where" it happened, one item at a time. Even as the count grows, events do not form a continuous line; their distinguishing feature is that they sit as points along the time axis. This form is effective when you want to give a reason to a change in numbers. A metric tells you the fact that the response time graph jumped at 14:00, but the fact that a release took place at 14:00 is written nowhere in the metric. Only when both are laid out on the same time axis does a line connect the change and its cause.

Where events come from

The sources fall broadly into 3 lineages. The first is what Datadog itself creates: Monitor state changes, Watchdog detections, and new errors found by Error Tracking automatically become events. The second comes from the Agent and installed integrations. Over 100 integrations support event collection, with Kubernetes / Docker / Jenkins / Amazon ECS as representative examples (as of September 2026; Source: Event Management). The third is what you send yourself: you can bring in deployments, configuration changes, change requests, and alerts arriving from third-party tools.

The shaping step is inserted so that records with different shapes from each source can be aligned into a state where they can later be searched under the same conditions.

Seeing with your own eyes that it broke right after a change

Events are at their most powerful when used as a change history. If you send an event with every deployment, you can overlay those markers on your dashboard graphs. If a release point stands right below the line where the error rate rose, the candidate causes narrow at once. Conversely, if it broke in a time window with no points, you know it is your turn to suspect an external factor rather than your own changes. Without this, every incident spawns the work of digging up the change history from somewhere else and matching timestamps by hand. Events are the mechanism for finishing that matching inside the monitoring interface from the start.

You can raise alerts with events as the condition

Ingested events are not only for viewing; they also become material for notifications. Monitors include a type that uses events as its search condition, and you can raise an Alert based on how many events matching the specified condition occurred within a given time. This form is suited to watching for occurrences that are hard to express as numbers, such as a container being force-killed or a configuration failing to apply. A mechanism for grouping notifications by correlating events with one another is also provided; this is a feature for reducing how often things fire and keeping the volume at a level a human can read.

The allocation and billing are determined by host count

Custom events that you send yourself have an allocation. The Pro plan includes 500 per host monitored by Infrastructure Monitoring, and the Enterprise plan includes up to 1,000. The excess is billed at 2 USD (annual contract) to 3 USD (on-demand) per 100,000 events (as of August 2026; Source: Datadog Pricing). The prices in this article are examples at their respective points in time and do not reflect price revisions after writing. Because this allocation is counted as an average across the entire account, it is not strictly partitioned host by host. What matters in practice is that the total is nonetheless determined in proportion to the host count. If you design a setup with few hosts to send an event per request, you reach the limit early. The basic division is to restrict what you send to occurrences you will later want to look up by name, and to count fine-grained occurrence frequencies as numbers. Attach the environment names and service names that serve as search axes as Tags.

Can logs substitute for it?

The question of whether the same thing can be done with logs comes up often. Even if you stream deployment records into Log Management, searching itself still works. The differences are lightness of handling and lifespan. Logs incur retention periods and costs for whatever you put into indexes, and among millions of lines flowing per day, a single line recording a change gets buried. Events are premised on being used in limited numbers, as the order of magnitude of the allocation, 500 per host, indicates, and they receive dedicated handling such as overlay on graphs and tracking of state changes. The rule of thumb for deciding is whether you will look up that one item by name six months later as "the change on that day." If you will, use an event; if you will only look at trends in bulk, leaving it in logs is enough.