Operations | Monitoring | ITSM | DevOps | Cloud

When a PostgreSQL query runs slowly, engineers often start with EXPLAIN ANALYZE. The output is a tree of plan nodes, each one describing a step the database took to execute it. A query with several joins and a subquery can produce 20 or more nodes. But the plan gives no visual indication of which node corresponds to each clause in the SQL text. Diagnosing the problem means viewing the plan in one window and the query in another, manually tracing connections between them.

AI adoption is accelerating across organizations, and spending often follows a similar pattern: rapid growth, multiple providers, and limited visibility into where costs originate. Each provider exposes billing data differently, with distinct schemas, dimensions, and interfaces. FinOps and engineering teams often spend significant time consolidating fragmented data, only to end up with partial attribution and limited context about who or what generated the AI spending.

Micro-frontend architectures, where independent teams build and deploy separate parts of a frontend application, introduce an observability challenge: Telemetry data is fragmented across services, making it difficult to determine which micro-frontend caused a performance degradation or error spike.

When your database performance degrades, diagnosing the root cause is rarely quick or straightforward. Your existing tools might surface metrics like CPU utilization, wait events, and query duration, but then leave you to correlate the data and identify what went wrong. Worse, what first appears to be the root cause can often just be a downstream effect of multiple interrelated issues.

Modern government missions depend on software platforms that can perform under demanding conditions. As agencies update systems that support public safety, benefits delivery, financial operations, and national priorities, they face security and compliance requirements that shape how technology is adopted as well as how it is built, operated, and evolved over time.

Cloud cost data is most useful when teams can adapt it to their own reporting and planning needs. In addition to viewing cost breakdowns, FinOps teams often need to calculate forecasts, reshape datasets, and present tailored views to finance and leadership teams. In many workflows, those steps happen outside the observability platform. Once the data is exported, it quickly becomes outdated and requires repeated manual updates.

Built on Postgres, Supabase is an open source, all-in-one backend platform for developers who want to ship applications without managing infrastructure. This makes it especially popular with frontend developers and vibe coders who may have little to no database expertise. Datadog's Supabase integration provides high-level infrastructure metrics, but developers also need query-level visibility to easily diagnose, optimize, and trace performance issues back to their source.

In the latest episode of This Month in Datadog, Jeremy shares how to run autonomous Cloud SIEM investigations, remediate vulnerabilities with auto-generated fixes, and use natural language to explore Datadog. Later, Sumedha Mehta spotlights the Datadog MCP Server, which gives AI agents real-time access to Datadog’s observability data. Then, Chetan Sharma walks through Datadog Experiments, which measures how product changes impact the user journey.

Security and platform engineering teams rely on context-rich logs to investigate threats, prioritize incidents, and meet compliance requirements. Context is often stored separately from applications that generate logs, in sources like threat intelligence feeds in Snowflake, asset lists in Amazon S3, ownership data in ServiceNow CMDB, and risk scores produced in Databricks.

When developers and SREs design application tests, they often prioritize user workflows and API availability. Extending that suite with network tests that match your app’s traffic protocols can reveal whether issues originate in the network or application layer. In this post, we’ll explore how you can design effective network tests using the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Internet Control Message Protocol (ICMP), including.