Operations | Monitoring | ITSM | DevOps | Cloud

PayPal runs six data centers, each with around 60,000 containers. Their 30,000 employees spin up nearly 10,000 test environments every day — roughly 6 to 10 every minute. Each environment requires three config updates: one to create the virtual service, and additional calls to configure and deploy the applications. Do the math and you get a staggering 30,000 config updates per day.

Regular DR testing is no longer a compliance checkbox — it is a critical engineering discipline that determines whether an organisation can survive a real cloud outage with its services and revenue intact. As the AWS Middle East incident demonstrated, regional cloud failures can strike without warning and defeat standard redundancy models, making untested DR plans dangerously unreliable.

The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards.

Not long ago, adding a new cost connector to CloudZero was a serious undertaking. We’d task multiple engineers, build in extended review cycles, run a private preview period. But a single connector could take up to two months from kickoff to customer hands. For the major cloud providers, that timeline was acceptable. The size of the investment matched the scale of the integration. But the tools landscape has changed. Our customers’ teams don’t just run on AWS and Azure.

Last week, a fleet of autonomous robotaxis in China suddenly stopped working—at scale. Over a hundred vehicles stalled across a city, stranding passengers in traffic and raising immediate concerns about safety, reliability, and trust in autonomous systems. This wasn’t just a bad day for self-driving cars. It was a distributed systems failure, one that happened in the physical world, not just in dashboards.

OpenTelemetry is great at answering one question: “what just broke?” The problem is that most teams need a different answer first: “what is about to break in this release?” That is where trace-based testing comes in, especially for teams running a vendor-neutral OTel stack (Collector + Tempo/Jaeger + Prometheus) and needing deterministic release gates.