The action from the postmortem
gets done this time.
Datadog Work Management, formerly Case Management, is the queue where alerts, correlated events, security signals and postmortem actions become work items with an owner and a state. We implement it next to the incident process, route the right things into it, and under Critical Support we are the ones working the queue.
Quick facts
Related
- Incident Management, the incident that produces the actions
- Software Catalog, the owner a work item is routed to
- Teams, who the queue belongs to
A queue that sits where the evidence is
The postmortem names three actions. Two go into a ticketing tool the on-call engineer does not open. The third is agreed verbally. Four months later the same cause takes the same service down, and the actions are rediscovered in the document. Work Management puts the action next to the graph, the log and the monitor that justified it.
One work item, many sources. A monitor, a correlation pattern, a Cloud SIEM signal, a Bits Investigation or a person can each raise one. The item carries the telemetry that raised it, so triage starts with evidence rather than a search.
Projects shaped like the team. Work types are configured per team and every item shares the same core fields, audit trail and integrations. A platform team and a security team can run different queues on one record format.
Assigned to a person or an agent. The assignee can be an engineer or a Datadog AI agent, and the agent's actions land on the same timeline as a human's. What was done, by whom, is one list.
Synced with the tools already in use. Two-way sync with Jira, Linear and ServiceNow, pull requests linked from GitHub, notifications in Slack and Teams. The engineer who lives in Jira does not have to move.
A queue nobody reads, a sync that runs one way, and a state called "In Progress" that means "forgotten"
How it bills. Datadog states that Work Management is included with the platform at no additional charge. The agents that can be assigned to a work item draw on AI Credits, which is a separate meter, and a workflow fired from a work item counts as a workflow execution. We publish nothing on rates. The meter that matters here is attention, and attention is what a managed queue buys.
The configuration traps. Every monitor routes into the queue, so the queue is the alert feed with a different name. Nothing is assigned on creation, so items wait for the one person who triages. Jira sync is set up in one direction and the two systems disagree within a fortnight. The postmortem template writes actions into the document and not into a project, so the actions have no owner, no date and no state. Projects are created per incident and never archived, so the project list is a history of bad weeks. None of these is an error in the product. Each is a routing decision nobody made.
Field noteThe most common gap we see is the postmortem that produces actions and the queue that never receives them. The two live in different tools, owned by different people, and the handoff between them is a meeting.
Field noteWork items are created from every monitor because Case Management was the first notification channel somebody wired up. The queue fills at the rate the estate alerts, and the useful items are found by scrolling.
Field noteThe pattern we keep finding is a one-way Jira sync. Items go out, status does not come back, and the Datadog queue shows a dozen things as open that were closed in Jira months ago.
Field noteAn item sits in "In Progress" with an assignee who has left the company. The audit trail is complete and accurate. Nobody is reading it, because the queue has no review cadence and the item has no date.
Decide what deserves a work item before the first one is created
The Service Management Accelerator is a four-week, fixed-scope delivery that sets up Incident Management, Event Management, Workflow Automation and Work Management together. Work Management comes last in that order, because the queue should receive what the other three produce, and nothing else.
- Agree the sources. Which monitors, which correlation patterns, which security signals and which postmortem actions become work items. Most monitors do not. The list is short and it is written down.
- Design the projects and work types. One project per team that will actually work a queue, with the fields that team needs and no others. Per-incident projects are banned from the start.
- Set assignment on creation. Automation rules assign each new item to a team or a person from the service's owner in Software Catalog. An item without an assignee is a configuration error, and it is alerted as one.
- Wire the postmortem. Actions from the Incident Management postmortem template become work items in the owning team's project. Each is created with a due date on the day the postmortem is published.
- Connect the ticketing tools both ways. Jira, Linear or ServiceNow sync configured in both directions and tested with a round trip, so a close in either system closes the other.
- Hand over the queue, with its analytics. The projects, the rules, the sources and the sync, documented. The time to assign and time to close dashboards switched on, with the baseline recorded on the day we finished.
Access is admin on the Datadog organisation, plus an integration account on the ticketing tool with permission to create and update issues in the agreed projects. We do not need access to your source repositories to implement Work Management.
A queue is only as honest as the last time somebody closed something
Teams change, sources change, and a rule written for last quarter's estate routes this quarter's alerts to a person who moved on. Under Critical Support, our engineers work the items that sit in the runtime we operate and review the rest with you every month. Managed Observability keeps the routing matched to the estate.
Every month, the queue is reviewed. Items past their date get a decision: done, rescheduled with a reason, or formally dropped. Nothing stays "In Progress" because nobody looked.
Routing follows the org chart. When a team splits, a service changes owner or a person leaves, the assignment rules change in the same week, because we check them against Software Catalog and Teams.
The sync is kept honest. A monthly reconciliation between the Datadog queue and Jira or ServiceNow. Items that disagree are fixed, and the reason the sync drifted is fixed too.
The incident actions are ours to do. Postmortem actions that sit in the runtime we operate go into our improvement backlog and are closed by our engineers, with the closure recorded on the work item for the next customer questionnaire.
We operate the stack. You own the product.
A ticketing tool records that something was supposed to happen. A managed queue is a commitment that it will. We implement Work Management so the record is accurate, and then we are one of the teams the work is assigned to. The projects, the rules and the history stay in your Datadog, and you can take the queue in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Work Management, answered plainly
Is Datadog Work Management the same as Case Management?
Yes. Datadog renamed Case Management to Work Management in 2026, and cases became work items. Existing cases carried over without a migration and existing integrations kept working. The API and permission names still use the word case. The change is more than a rename: a work item can now be assigned to a Datadog AI agent as well as a person, and the agent's actions are recorded on the same timeline.
How is Datadog Work Management billed?
Datadog states that Work Management is included with the platform at no additional charge. Two adjacent meters can apply. A workflow triggered from a work item is a workflow execution, and a Datadog AI agent assigned to a work item draws on AI Credits. We do not publish prices. We design the routing so the queue only receives work worth a person's or an agent's time.
Do we have to leave Jira or ServiceNow to use it?
No. Work Management syncs in both directions with Jira, Linear and ServiceNow, links GitHub pull requests, and notifies through Slack, Microsoft Teams and email. Engineers who live in Jira keep living there. What changes is that the item in Datadog carries the monitor, the graph and the log that raised it, so the person who picks it up starts with the evidence rather than a search.
Can a work item be assigned to an AI agent?
Yes. The assignee can be a Datadog AI agent built with Bits Agent Builder, chosen by hand or by an automation rule, and the agent runs with the permissions of the person who assigned it. Datadog lists the Work Management integration with custom agents as in Preview. We scope which work types an agent may take, and the outcome stays with a named engineer. Agents own the analysis. Humans own the outcome.
What does Critical Cloud do with Work Management every month?
Under Critical Support our engineers are assignees in the queue for everything that sits in the runtime we operate, including postmortem actions, and we close those items ourselves. Every month we review the queue with you: items past their date get a decision, assignment rules are checked against the current owners in Software Catalog, and the Jira or ServiceNow sync is reconciled. Managed Observability keeps the sources and routing matched to the estate.
- Datadog products: every product, and how we implement and run each one
- Incident Management: the postmortem whose actions land in the queue
- Event Management: correlation patterns that open one work item per cause
- Service Management Accelerator: incidents, events, workflows and work items set up in four weeks
A queue where things get closed.
Tell us where your postmortem actions live today. We will show you what they look like as work items with owners, and what it takes for us to be one of the owners.