Operations | Monitoring | ITSM | DevOps | Cloud

On the first episode of This Month in Datadog in 2026, Jeremy covers how you can protect agentic AI applications with AI Guard, stay up to date and collaborate during incidents with five Incident Management releases, and ship software with confidence using Feature Flags. Later in the episode, Kevin spotlights Datadog Data Observability, which enables you to detect data quality and pipeline issues early.

Achieving end-to-end observability for applications is a top priority for organizations today, but instrumenting for both frontend and backend monitoring can be a significant hurdle. What complicates matters is that the SREs and DevOps teams responsible for deploying monitoring tools typically don’t own frontend code or have the context needed to safely modify it.

Mobile app users form opinions quickly. A slow or inconsistent startup experience can frustrate them before they reach the first screen, increasing the likelihood that they abandon the app or fail to complete key actions such as signing up or making a purchase. However, app teams often lack reliable signals that explain why startup performance varies, making it difficult to improve the user experience.

This article is part of our series on how Datadog’s engineering teams use LLM Observability to build, monitor, and improve AI-powered systems. Organizations are building AI agents that help users automate work, analyze data, and interact with complex systems through natural language. As these agents become more capable, they also become more complex and exposed to risks such as prompt injection, data leaks, and unsafe code execution.

As organizations scale their services and adopt AI-assisted coding, code changes are landing faster and in greater volume than ever before. While this powerful new practice is accelerating the pace of development, it is also increasing the likelihood that untested code may slip into repositories without detection. What makes this problem even worse is that most teams have no reliable way to know which code is covered by tests.

Modern CI/CD pipelines have automated the hard work of building, testing, and deploying our code. But for many teams, that’s where the automation stops. The most critical part of a release, turning a new feature on for real users, is still a stressful, manual process. An engineer cautiously ramps up traffic to 5%, then 10%. The whole team stares at dashboards, trying to see if anything breaks. If something does, they scramble to manually roll back.

Modern enterprises rely on software-defined wide area networks (SD-WANs) to connect branch offices, data centers, and cloud environments. While this flexibility improves resiliency and performance, it also increases operational complexity.

SREs and application developers rely on telemetry data to understand and improve their systems. As organizations scale and evolve, those systems generate an ever-growing volume of metrics, logs, and traces. But more data alone does not make it easier to improve performance or reliability: Identifying meaningful optimizations still requires careful investigation and analysis.

As enterprises scale, teams often find it harder to identify user-reported issues. Software-defined wide area networks (SD-WANs) can make it easier to add branch offices, but they can also make it more challenging to distinguish connectivity degradation from changes in application behavior. FortiManager provides a centralized control plane for Fortinet Secure SD-WAN and reduces operational complexity.

As codebases grow across many different services, it becomes harder to see what test suites actually cover. AI-assisted development and faster release cycles increase the volume of changes landing in repositories, raising the risk that untested code will make it through to production. To maintain a high standard, teams need clear and scalable visibility across repositories, consistent testing standards, and a way to catch blind spots before they reach users.