Operations | Monitoring | ITSM | DevOps | Cloud

Mature experimentation programs eventually have to report the cumulative impact of their shipped changes. The request might come as an ROI story for leadership, a revenue update for finance, or a gut check on the quarter’s progress. The tempting shortcut is to sum the observed lift from each winning experiment and report the total. That naive sum almost always overstates the truth because of a statistical artifact called the winner’s curse.

Teams often track operational work across spreadsheets, Slack threads, Jira tickets, and whatever system generated the original alert or signal. This fragmentation makes it difficult to maintain a consistent record of what needs attention, who or what is addressing the issue, and what has already happened. As AI agents take on more responsibility for investigations, triage, and code changes, the number of handoffs grows, making ownership, status, and history even harder to preserve.

AWS Lambda durable functions let you build long-running, multi-step workflows for use cases such as payment processing, order fulfillment, and AI workflows with human approval. A single durable execution can pause for a wait or callback, retry failed work, and resume in a fresh Lambda invocation without losing its state. The strong resilience provided by durable executions, however, creates an observability challenge because each invocation produces its own telemetry data.

Data pipelines are systems for moving and processing data. They are made up of concatenated services and data stores that programmatically ingest data from upstream sources; filter, transform, enrich, and route that data; and deliver it to downstream consumers.

An account can show signs of disengagement long before a renewal conversation begins. Users may stop returning to a core workflow, stall during onboarding, or skip a newly released feature. Product teams often see these signals only at the user level, while annual recurring revenue (ARR), plan, renewal date, and ownership data remain in a customer relationship management (CRM) system or data warehouse.

Serverless platforms like AWS Lambda, Google Cloud Run, and Azure Container Apps let teams run applications without managing infrastructure. However, getting full visibility into those workloads has traditionally required a lot of manual setup. A single team may deploy serverless applications across multiple clouds by using tools such as Terraform, AWS SAM, AWS CDK, and the Serverless Framework. Each of these platforms, runtimes, and deployment tools requires its own instrumentation steps.

Teams supporting user-facing applications rely on session replays to understand user friction. But resolving an issue or improving the user experience takes more than watching a replay. Engineers, product managers, and designers first need to find the right sessions to investigate, then quickly learn what happened at the key moments. Once they’ve investigated a replay, they need to share what they found across product, design, support, and engineering so that the right teams can act.

In July’s episode of This Month in Datadog, Ruxanda Lueck joins Jeremy for a conversation about how you can confidently evaluate and release features that contain AI-generated code. She also discusses her career trajectory from containers to AI, how agentic workflows impact trust during feature development, and the challenges of testing nondeterministic agent behavior.

If you run a cloud security program, two questions follow almost every security finding: Who owns this? And how important is it? Many security tools answer those questions with static metadata such as owner tags, business criticality labels, and manually maintained inventories of critical assets, known as crown jewels. But cloud environments aren’t static. Teams reorganize, services change hands, and dependencies evolve.

When designing effective error handling for React apps, the troubleshooting information you collect and display is critical. React errors can stem from a variety of causes, including user misconfiguration, backend and network issues, and mismatches in browser environments. Instrumenting your code to log critical context, including feature names, user data, and session activity, enables you to quickly identify where these errors originate.