When an incident fires at 2 AM, your team's ability to respond effectively depends less on the tools they have and more on the context those tools can surface. Datadog product managers Jesse and Sam explore how platform teams can build the foundational context layer that makes incident response faster, smarter, and more effective - and how AI can amplify those efforts when the groundwork is solid.

Main insights

• AI amplifies existing organizational strengths or weaknesses - faster delivery only helps if incident readiness keeps pace
• Service context (ownership, on-call, runbooks, dependencies) must be centralized and maintained before incidents occur, not reconstructed during them
• The internal developer portal catalog serves as the single source of truth that both human responders and AI agents rely on during incidents
• Connecting the full incident lifecycle - from alert to investigation to postmortem - in one platform keeps context flowing continuously through each stage

Jesse Wu and Sam Rodman are product managers at Datadog, focusing on incident management and the internal developer portal, respectively. Their combined expertise spans the full incident response lifecycle, from the platform foundations that enable readiness to the tools that support real-time response and continuous learning.

You can watch the full discussion here if you missed it.

AI as an amplifier: What DORA research tells us

Jesse opened with a framing that every platform team needs to internalize: "AI is an amplifier. It can amplify the strengths of a high performing organization but it can also amplify existing dysfunction."

This insight, grounded in DORA research, redefines how platform teams must think about AI-assisted operations. As AI accelerates software delivery, a critical question emerges: are you also improving the systems that responders rely on when something goes wrong? Faster delivery is only a net positive if ownership, operational readiness, and incident response can keep pace. Without that foundation, AI simply helps teams break things faster.

The implication for platform engineers is direct: the quality of your internal developer portal incident response capability is determined before the incident ever fires.

The context problem: What responders need immediately

Fast incident response depends on having the right service context available the moment an alert fires. Jesse and Sam identified the essential elements every responder needs:

• Who owns the service
• Who is on call and how to escalate
• Which runbook to follow
• What the service depends on upstream and downstream
• Whether the service meets production readiness standards

Two persistent problems undermine this. First, keeping this information current is tedious manual work that teams deprioritize under delivery pressure. Second, the infrastructure for centralizing all of this data doesn't always exist. The result: context that should be pre-built gets reconstructed during the response - exactly when your team can least afford the delay.

"Responders often have to search for this information after the alert fires," Jesse noted, "and then the result is a slower response and missed opportunity to improve readiness for the next incident."

The connected lifecycle: From alert to postmortem

Sam demonstrated how connecting the entire incident lifecycle in one platform solves the context reconstruction problem. When a monitor detects an issue and pages the on-call team, all service context from the catalog - ownership, teams, runbooks, dependencies - automatically populates the incident. You get the service, the environment, and every relevant team brought into context immediately, without anyone having to hunt for it.

The response itself happens where your team already works - in Slack or Microsoft Teams - where an incident channel is automatically created and the right people are pulled in. Every action throughout the investigation, including Slack messages, automations, and status updates, gets captured on a unified timeline. That timeline then becomes the foundation for the postmortem, eliminating the need to reconstruct what happened from scattered chat logs and fading memory.

This continuous flow of context - from alert through investigation through learning - is what separates a mature incident response practice from one that resets to zero with every new incident.

AI as a response partner, not just automation

During the demo, Sam showed how Bits AI works alongside human responders rather than replacing their judgment. When a responder asks "are there any related incidents?", Bits searches the entire Datadog implementation using both the service context from the catalog and semantic understanding to surface relevant history.

The AI goes deeper than simple search. Bits can run full investigations, examining metrics, logs, and traces to form and test hypotheses about root causes. "It's actually following different hypothesis threads to determine what we think is the right path to go down to get to the root cause," Sam explained. Investigation results post directly to the incident, where human responders can adopt them, challenge them, or add additional context.

This is the key distinction: AI works best here because it has rich, pre-built context to draw from. The catalog is what makes the AI useful. Without it, the AI has nothing meaningful to amplify.

The catalog: Your single source of truth

Jesse demonstrated the internal developer portal catalog as the foundation for everything else. "It's a free platform feature," she noted, "and it is the source of truth that incident management reads from."

The catalog contains every field responders rely on:

• Owner and team information
• On-call schedules and escalation policies
• Runbooks and documentation links
• Source code references
• Deployment history
• Request, error, and latency metrics
• Dependency maps showing upstream and downstream services

If you already use Datadog APM, logs, RUM, or universal service monitoring, your catalog is already partially built - instrumented services appear automatically. The remaining work is a one-time declaration via YAML files, Terraform, or API.

The historically hard part - keeping that metadata accurate over time - is where Datadog is investing heavily. The catalog manager surfaces gaps and suggests fixes automatically. "We are building the catalog manager which shows recommendations that surface gaps and suggest fixes so that your catalog stays accurate over time without having someone have to manually audit it," Jesse explained. The goal is a self-healing catalog that maintains accuracy without ongoing manual intervention.

Measuring readiness with scorecards

To track progress toward a complete catalog, Datadog provides scorecards with 10 out-of-the-box rules covering observability, ownership, and production readiness. Platform teams can add custom rules to reflect their own standards.

The ownership and documentation checks verify whether services have code repositories defined, contact teams assigned, and documentation linked. Services that fail these checks surface clearly, and platform teams can use Datadog workflows to automatically remediate issues or use catalog manager recommendations to fill in missing context.

Jesse made the connection explicit: "The readiness standards that platform teams set in the portal are the same data that the responder relied on during the incident." This is <a href="https://platformengineering.org/blog/what-is-platform-engineering">platform engineering</a> work that directly determines incident response speed and effectiveness - and scorecards make that value visible to the broader organization.

Post-incident learning: AI as a writing partner

After an incident resolves, the unified timeline becomes the foundation for the postmortem. Datadog can generate a draft automatically from all captured context. But Jesse and Sam are taking this further, and their reasoning matters.

"The reality about how postmortem generation works in that post-incident process is that it is really a learning opportunity, not something that you just want to automate away," Sam explained. Rather than a one-click document generator, Datadog is designing an AI partner that asks probing questions as you write - challenging responders to examine areas they may have glossed over, flagging parts of the analysis that aren't well defined, and ensuring the postmortem drives genuine learning rather than just checking a compliance box.

Integration with existing tools

For teams not fully consolidated on Datadog, the platform integrates with ServiceNow, Confluence, Sentry, Splunk, and Grafana. "Things work great when everything's together," Sam acknowledged, "but we also want to accommodate that journey knowing that you may be in other tools along the way."

Bits investigations can pull context from external sources, and incident data can sync to ServiceNow or other systems of record. The philosophy is to meet teams where they are while providing the most value when context is unified.

​

If you enjoyed this, check out more great insights and events from our Platform Engineering Community.

​

Key takeaways

• Build the context layer before incidents happen. The service catalog with ownership, on-call schedules, runbooks, and dependencies must be centralized and maintained continuously. This pre-incident investment is what determines how fast and effectively your team responds when something breaks.
• Connect the full incident lifecycle. Context must flow from alert to investigation to postmortem to readiness improvements in one continuous loop. Fragmented tools force responders to reconstruct information at the worst possible moment, slowing recovery and degrading learning.
• Use AI to amplify, not replace, human judgment. AI investigations and postmortem assistance work best when they have rich, pre-built context to draw from. The platform team's work building and maintaining the catalog is what makes AI effective - without it, there is nothing meaningful to amplify.
• Measure and maintain catalog completeness. Scorecards and automated recommendations help platform teams track readiness and prevent context drift over time. A self-healing catalog that stays current without manual audits makes incident readiness a continuous state rather than a periodic effort.