Operations | Monitoring | ITSM | DevOps | Cloud

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.

On April 1st, I joined Akshay Utture from Augment Code for a webinar on how AI agents use production feedback to improve code.

Autonomous IT is the result of a long operational evolution, from static monitoring and rule-based automation to AIOps and now to systems that can increasingly diagnose, prioritize, and act within defined guardrails. Autonomous IT gets talked about like it appeared out of nowhere. As if someone flipped a switch and suddenly systems started managing themselves. The reality is far less dramatic and far more instructive. What we’re seeing today is the result of decades of incremental progress.

Effective network monitoring requires path validation, not only device polling. Traditional Network Monitoring System (NMS) tools were built for static networks, not today’s hybrid reality. You poll devices, check interface counters, and still struggle to explain why users complain about latency. Traffic moves across SD-WAN architectures, cloud routing layers, and public internet paths that device metrics never capture.

Fragmentation limits AI automation because context is split across systems, forcing humans to bridge the gap. Most IT environments are fragmented by design. Observability data lives in one set of systems, investigation happens in another, and execution sits behind separate tools with their own ownership and controls. During an incident, context does not move with the work.

For years, IT operations teams have been trapped in a frustrating paradox: the data they need to solve critical issues is right at their fingertips, yet entirely out of reach. Accessing it requires engineers to master complex, platform-specific query languages, dig through endless layers of dashboards, and hunt for the exact visualization that holds the answer. Under the intense pressures of modern speed, scale, and complexity, this rigid model is breaking down.

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.

If you manage more than a handful of monitors, you have probably wanted to define them in code rather than clicking through a dashboard. Terraform is the standard tool for that in the infrastructure world, and now there is a Terraform provider for Hyperping. Develeap, a DevOps consultancy, built this provider while managing monitoring for 57 tenants at scale. They needed infrastructure as code for monitors, status pages, and incidents, so they built it, tested it in production, and open-sourced it.

Develeap, a DevOps consultancy, has been using Hyperping to manage monitoring across 57 tenants. That real production usage led them to build a set of open-source tools that extend Hyperping into the infrastructure-as-code, Python, and observability ecosystems. The result is four interconnected projects, each driven by a concrete operational need.