Workflow Automation
A mechanism that automatically executes, inside Datadog, a sequence of steps such as filing tickets, sending notifications, and operating cloud resources, triggered by monitors or security signals. You assemble triggers, steps, branches, and retries in the UI, turning routine human work into an executable flow.
What it does
Creates "workflows" that execute actions in order, starting from triggers such as monitor alerts, security signals, incidents, schedules, or manual runs. Actions range from cloud and SaaS operations to operations inside Datadog, all listed in the official catalog, and you can insert if branches, loops, HTTP requests, and data transformation in JavaScript. You can also configure retries for failed steps and an alternate path on failure.
When to use it
Use it to automate procedures such as creating a Jira ticket and notifying Slack when an alert fires, increasing the instance count of an Auto Scaling Group when a threshold is exceeded, compiling an IP detected by a security signal into an investigation note before blocking it, or executing a rollback to a stable version from a dashboard button.
An everyday analogy
An assembly robot placed on a factory line. When a sensor (monitor) detects an anomaly, it performs the taught steps in the same order every time, from picking up the part (creating a ticket), to applying a label (notification), to setting the defective item aside (scaling adjustment). The behavior of stopping and calling a person when a situation it has not been taught arises can also be built in beforehand as part of the procedure.
Bottom line - turning a runbook into an executable flow starting from a trigger
Workflow Automation is a product that assembles everything from "the trigger" to "a sequence of operations" as a single flow inside Datadog and runs it automatically. The official documentation explains that you can combine actions that connect to your infrastructure and tools, insert data operations and logic operations, and build flows that include branches and decisions, and states that the number of actions exceeds 2,000 (as of September 2026, source: Workflow Automation). The work people do after an alert fires, routine steps such as cutting a ticket, notifying the person on duty, or scaling up the target, can be replaced with automatic execution starting from the monitor. For an organization where "15 minutes for filing and contacting" disappears in every incident, the value of adoption is that those 15 minutes can go to recovery. Because there is no line for it in the public price table, this article does not write a figure for the unit price. The how-to page states that "published workflows incur costs based on the number of executions" and directs you to the pricing page (source: Build workflows).
- Trigger: monitors, security signals, incidents, dashboard buttons, Slack, API, schedules, manual, and more
- Steps: actions from the official catalog (cloud, SaaS, operations inside Datadog) plus transformation via HTTP requests and JavaScript
- Control: if conditions, switch, for and while loops, waits, retries on failure and alternate paths
- Publishing: once tested and published, it runs at every trigger and the execution history is kept
The 11 trigger types and how to choose the execution identity
The official list of triggers has 11 types, and a single workflow can have multiple triggers (as of September 2026, source: Trigger a workflow). What is easy to overlook is the execution identity. Each execution runs under one Datadog identity, and you choose the owner, the person who ran it, or a service account with Run as. For triggers where no person is involved, such as schedules or the API, the owner or a service account is required. This identity determines the connections that can be used, the Datadog resources that can be read and written, and the name that remains in the audit trail (source: Access and Authentication). The more automation you add, the more "under whose permissions did it run" gets asked, so the first design move is to run production workflows under a service account and narrow permissions with RBAC.
| Trigger | Starting point |
|---|---|
| Manual | Run on the workflow screen |
| Dashboard | Run Workflow widget (maps template variables to inputs) |
| Monitor | Monitor notification (automatic by default, can be switched to manual) |
| Incident | Incident events, or manually from the incident screen |
| Security | Security signals and findings (automatic via notification rules, manual from the panel) |
| Software Catalog | From a catalog entity |
| GitHub | Webhook on the GitHub side (creation permission required) |
| Slack | Manual, or an emoji reaction (requires the Datadog App to be installed) |
| API | API key and an application key with the workflows_run scope |
| Schedule | Time (runs under a service account) |
| Another workflow | Calling a child workflow via the Trigger Workflow action |
When a Webhook suffices, and when a Workflow is needed
A Webhook is an outlet that pushes a notification over HTTP to a URL you decide, and what happens next is built by you on the receiving side. Workflow Automation places that "what happens next" inside Datadog. There are four differences. Credentials are managed on the Datadog side as Connections and inherit the credentials of integrations. Failed steps can be retried with a set count and interval, and when retries run out the flow can proceed to an alternate path. You can branch with if conditions, switch, and loops. Success or failure can be notified to Slack or Microsoft Teams, and the execution history is kept (as of September 2026, sources: Build workflows, Getting Started with Workflow Automation, Access and Authentication). If you have an automation platform with a receiving endpoint that can handle both branching and retries, a Webhook suffices. If not, a Workflow lets you skip building the authentication and failure handling yourself.
| Aspect | Webhook | Workflow Automation |
|---|---|---|
| Direction | One way from Datadog to a URL | Passes the result of an action to the next step |
| Where processing lives | Built by you on the receiving server | Inside Datadog (actions and logic) |
| Credentials | Prepared on the receiving side | Managed in Connections, inheriting integration credentials |
| On failure | Depends on the receiving side's implementation | Retry count and interval, alternate path on failure |
| Branching and loops | None | if conditions, switch, for and while, waits |
| Records | Logs on the receiving side | Execution history and an audit trail by the Run as identity |
Connections that automatically create incidents and cases
The action catalog lists not only external SaaS but also operations on Datadog itself. As of September 2026, you can find actions for Datadog Incidents (create, update status, and so on), Datadog On-Call, Datadog Events, and creating a case from a security signal or a security finding (source: Action Catalog). You can build a single flow in which a monitor fires, an incident is declared, a page is sent to the On-Call responder, and a case is created as the receptacle for the investigation. However, the incident side separately has Incident Automations, which come with context built in and no additional charge, and the official guidance is to use workflows when treating the incident as one of multiple triggers (source: Trigger a workflow). Whether to start from alerts bundled by Event Management or from individual monitors is a design point directly tied to the number of executions.
External service actions and how to read the limits
Catalog actions are grouped by destination, with Slack, Jira, ServiceNow, PagerDuty, GitHub, Kubernetes, Statuspage, operations on each cloud, and more. As generic actions there are also HTTP requests, data transformation in JavaScript, flow control (if conditions, switch, sleep, for, while), and reuse of saved actions (as of September 2026, sources: Actions, Workflow Logic). The limits for paid accounts are as in the table below, and anything beyond them is processed in order from a queue (source: Limits). Because the limit of 50 per minute from the same source kicks in during a storm of the type "one monitor fires 500 times," the safe order is to finish notification aggregation on the monitor side first and then connect the workflow. App Builder is a separate product that uses the same action catalog (source: Action Catalog) and is not covered in this article.
| Item | Limit |
|---|---|
| Workflow creation | 500 per minute per organization |
| Workflow executions | 200 per minute per organization |
| Executions from the same source | 50 per minute (a specific monitor, for example) |
| Queue | 500 per organization |
The line between decisions that may be automated and decisions people keep
What can be written as a procedure can be automated, and what cannot, cannot. By this criterion, the four things you may hand over are filing, contacting, information gathering, and reversible mitigation. All of them can be undone if they fail, and the execution history remains. What people keep are irreversible operations (deletion, configuration changes involving payments) and judgment about the cause. Workflows have tools for embedding this boundary in the procedure: a manual trigger, a Slack emoji reaction, the Slack actions Make a decision and Prompt user with modal, and a step that waits until a condition is met, so you can insert a human confirmation and then continue (as of September 2026, sources: Trigger a workflow, Build workflows, Action Catalog). Start the first workflow from the official introductory example, "when a monitor fires, create a Jira ticket and send the link to Slack," and leave the decision part as a manual trigger; you can then widen the scope later.
| Category | Example | Reason |
|---|---|---|
| May hand over: filing | Create a ticket in Jira or ServiceNow | Reversible, history remains |
| May hand over: contacting | Notify Slack or Microsoft Teams, page On-Call | Delay is a direct loss |
| May hand over: information gathering | Collect related logs and metrics and attach them to the ticket | Read-only, no side effects |
| May hand over: reversible mitigation | Capped scale-out, disabling a feature flag | The procedure to revert is clear |
| People keep: irreversible operations | Deleting resources, configuration changes involving payments or contracts | Failure cannot be undone |
| People keep: judgment about the cause | Determining the root cause, choosing the permanent fix | Cannot be written down as a procedure |
Things to watch out for
- This article is based on the official documentation as of September 2026. Trigger types, action catalog entries, and limit values can change, so when designing, give priority to the lists in the official documentation.
- Because there is no line for Workflow Automation's unit price in the public price table, this article does not write a figure. The official documentation states that published workflows incur costs based on the number of executions (as of September 2026). Check pricing on the official pricing page.
- This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.